在我到目前为止看到的示例中,具体值总是传递给视图 - 无论是作为单独的变量还是作为数组。
Laravel文档中的示例:
$view = View::make('greeting')->with('name', 'Steve');
将模型传递给视图是不是一个坏主意?
在我的控制器中,我使用:
return response->view('quote.render', Quote::find($id))
而不是像:
return response->view('quote.render',
['date' => $quote->date,'clientName' => $quote->client->name, 'items'=> $quote->items])
在我的视图(刀片模板)中,我可以使用这样的模型:
To: {{$quote->client->name}
Date: {{$quote->date}}
我的优势在于我可以立即掌握所有模型的数据 - 如果模型发生变化(获得更多属性),我不必更改控制器以传递新数据......它也感觉更清洁。
这种方法有什么缺陷吗?或者说这是不好的理由?感觉不错 - 但我没有在例子中看到它。
答案 0 :(得分:6)
将模型传递到视图中是很好的,这样做的好方法是这样的:
public function show($id)
{
$thing = Thing::findOrFail($id);
return view('showAThing')->with('thing', $thing);
}
如果数据库中不存在该项,则在此上下文中使用findOrFail()
将引发404错误。这很有用,因为如果您尝试使用$thing
= null
呈现视图,那么您将遇到未处理的异常。
修改强>
编辑要更新此内容,findOrFail
不会自动抛出404错误。它将抛出一个ModelNotFound
异常,但您可以设置错误处理程序来捕获它并执行您认为最合适的任何操作(在我的情况下,我将返回404响应)。
答案 1 :(得分:0)
Liskov替代原则 程序中的对象应该可以替换为其子类型的实例,而不会改变该程序的正确性
依赖性倒置原则应该“依赖于抽象。不要依赖于结核和#34;
单一责任原则 一个班级应该只有一个责任(即软件规范中只有一个潜在的变化应该能够影响班级的规范)
视图不应该依赖于模型,也不应该知道它是如何工作的。
答案 2 :(得分:-1)
如果你想快速构建某个项目或者在项目上工作,你知道很长一段时间都不会增长或维护是的,否则你应该考虑更多地抽象你的代码,参见SOLID PATTERN