提问
什么是最佳实践在哪里放置ORM的实现在一个类似MVC的软件应用程序？
我使用的是Laravel，带有Eloquent，默认的ORM。
文档中暗示了ORM调用在Controller中很好，但这并不正确。
例如，假设我想要一个用户。User::findOrFail($id)是我需要的代码。documentation在控制器内部有这个功能（最新版本V。10个基本控制器
想象一下，我在整个项目中的100个地方都有这段代码，我需要再对它进行一次检查，也许是为了让用户也对他们的帐户进行标记。这有点麻烦，但如果它在模型中，我会简单地更新模型方法。
在此示例中的示例模型方法：
function get_user_by_id($id)
{
return User::findOrFail($id);
}这样做的缺点是模型很快就会变得巨大。
那么，这里的最佳实践是什么？
2条答案
按热度按时间xriantvc1#
你应该放在哪里？
问问自己是否需要封装这段代码。如果你回答是，把它放在模型里。否则，请继续从控制器调用它。
他们会变得太大吗？
Eloquent模型已经包含了很多功能，因为ORM使用的是活动记录模式，而不是像Doctrine这样的数据Map器。因此，您的模型可能不会变得太大，因为许多功能已经被继承了，并且您很少需要编写自己的模型。
您是否会对结构的更多控制感到更满意？
如果您过于担心数据库层的结构，并希望将separation of concerns principle应用于核心，请使用Doctrine。这样你会感觉好点但我真的认为Eloquent在大多数情况下都应该没问题。
o7jaxewo2#
TL;DR
ORM在模型上更好
这个问题是相对于PHP - Laravel的，但实际上，这是一个问题或任何遵循MVC设计的软件。Laravel是一个非常有主见的框架，它默认的结构更好地被遵循，但是它非常好地遵循了MVC设计。
现在，根据上面的mdn文档
1.视图：处理布局和显示。
1.控制器：将命令路由到模型和视图零件。
从这一点上，我们可以理解，最好的地方是模型。现在，为什么Laravel说“ORM调用在控制器中很好”？
我的猜测是因为，为了对用户更灵活，也为了更容易解释文档，Laravel是一个很棒的框架，既有经验也有初学者（或者工作不太好的公司），所以文档非常用户友好。
我看到很多公司把更多的商业逻辑放在控制器上，而模型则是简单的不透明的
类，使用DTO - Data transfer object和Domain Models的组合以及这些的组合：
我还看到一些公司将Model用作简单的DTO（或者称之为任何东西，只是一个没有逻辑的类，其中只有与SQL表匹配的字段）！
现在，使用ORM，改变了一点游戏，因为，是上述加的组合，使您能够在面向对象的方法上执行sql查询。
你可以将模型与实际的ORM实现解耦，正如这里所建议的In MVC, does an ORM represent the model?：
理想情况下，您希望将域模型类的形状与数据库表的形状分离。
但是，在模型上放置，可能是一个好的开始，但在控制器上是一个不好的做法
在这里，how to structure MVC models and ORM models非常有趣，因为他们正在谈论Entities，它们是DTO，但有一个更酷的名字。
相关