关于将 ORM 的实现放在类似 MVC 的软件应用程序中的什么最佳实践是什么？
我正在使用 Laravel 和 Eloquent，这是默认的 ORM。
文档暗示 ORM 调用在 Controller 中很好，但这并不正确。
例如，假设我想获得一个用户。
User::findOrFail($id)想象一下，我在整个项目的 100 个地方都有这段代码，我需要再次检查它，也许是为了让用户也对他们的帐户有一个标志。这有点麻烦，但如果在模型中，我会简单地更新模型方法。
此实例中的示例模型方法：
function get_user_by_id($id)
{
return User::findOrFail($id);
}
这样做的缺点是模型很快就会变得庞大。
那么，这里的最佳实践是什么？
你应该放在哪里？
问问自己是否需要封装那段代码。如果您回答是，请将其放入模型中。否则，继续从控制器调用它。
他们会变得太大吗？
Eloquent 模型已经包含了很多功能，因为 ORM 使用活动记录模式，而不是像 Doctrine 这样的数据映射器。所以你的模型可能不会变得太大，因为很多功能已经被继承，而且你很少需要自己编写。
对结构有更多的控制，你会更快乐吗？
如果你太在意数据库层的结构，想要将 关注点分离原则 应用到核心，请改用 Doctrine。这样你会感觉好些。但我真的认为 Eloquent 在大多数情况下应该没问题。
ORM 更适合 Model
这个问题与 PHP - Laravel 相关，但实际上，它是一个问题或任何遵循 MVC 设计的软件。 Laravel 是一个非常自以为是的框架，最好遵循它默认的结构，但是它很好地遵循了 MVC 设计。
现在，从上面的 mdn 文档
由此可见，最好的地方就是Model。 现在，为什么 Laravel 说“控制器中的 ORM 调用正常”？
我的猜测是因为，为了让 users 更灵活，并且为了更容易对文档进行解释，Laravel 是一个很棒的框架，经验丰富的人和初学者（或不太好用的公司）都可以使用，所以文档非常人性化。
我看到公司在控制器上放置更多业务逻辑，模型简单不透明
类，使用DTO-数据传输对象和领域模型的组合以及这些的组合：
我还看到一些公司将 Model 用作简单的 DTO（或随便称呼它，只是一个没有逻辑的类，其中只有与 sql 表匹配的字段）！
现在，使用 ORM，改变了一点游戏规则，因为它是上述加上的组合，使您能够在面向对象的方法上执行 sql 查询。
您可以按照此处的建议将模型与实际的 ORM 实现分离在 MVC 中，ORM 是否代表模型？：
理想情况下，您希望将域模型类的形状与数据库表的形状分离。
然而，穿上Model，可能是一个好的开始，但穿上Controller是一个糟糕的做法
在这里，how to structure MVC models and ORM models，非常有趣，因为他们在谈论Entities，它是DTO，但名字更酷。