我似乎无法找到可接受的答案。
我一直看到两件大事: 1) 不要在 Controller 中执行查询。这是业务或数据的责任。 2) 仅选择查询中需要的列。
我的问题是这两件事有点矛盾，因为 UI 中显示的内容实际上决定了需要查询哪些列。这反过来又导致了在 Controller 中运行查询的明显解决方案，而您不应该这样做。我在谷歌上找到的任何文档等似乎都很方便地忽略这个主题并假装这不是问题。
在业务层进行
现在，如果我采取另一种方式并查询业务层中的所有内容，那么我隐式地使所有数据访问密切反射(reflect) ui 层。这更多是查询函数和类的命名问题，而不是我认为的任何问题。
以一个应用程序为例，该应用程序具有多个 View ，用于显示有关客户的不同信息。自然的做法是将这些数据传输类命名为与需要它们的 View 相同的名称。但是，业务或服务层不了解 ui 层，因此这些数据传输类中的任何一个都可以真正为任何 View 重用，而不会破坏任何体系结构规则。那么，我该如何命名所有这些变体，比如说“客户”，其中一个选择名字和姓氏，另一个可能选择姓氏和电子邮件，或者名字和城市，等等。您只能将这么多类命名为“CustomerSummary”。
Entity Framework 和 IQueryable 很棒。但是，其他一切又如何呢？
据我了解，在 Entity Framework 中，我可以让数据层传回 IQuerable，其执行被推迟，然后只需告诉 IQueryable 我想要什么字段。太棒了。看来问题解决了。对于.NET。问题是，我也是做PHP开发的。几乎所有 PHP 的 ORM 的设计方式都完全违背了使用 ORM 的目的。甚至那些也不具备与 EF/IQueryable 相同的能力。所以我又回到了同样的问题，在 PHP 中没有解决方案。
总结
所以，我的总体问题是如何在不完全违反 ntier 架构的所有规则的情况下只获得我需要的字段？并且无需创建不可避免地必须设计为反射(reflect) UI 层布局的数据层？
最佳答案
And pretty much all of the ORMs for php are designed in a way that totally defeat the purpose of using an ORM at all.
Doctrine PHP ORM 提供了到属性/字段级别的延迟加载。您可以通过代理完成所有操作，代理仅根据需要查询数据库。根据我的经验，90% 以上的情况下，让 ORM 加载整个对象一次是更好的选择。否则，如果您不小心，您最终会多次查询数据库以获取相同的记录。除非您的数据模型很困惑并且行很长，否则额外的数据库喋喋不休是不值得的。
请记住，一个好的 ORM 还将提供内置的缓存层。一次填充整个对象并缓存它比让您的代码跟踪您需要在不同位置查询哪些字段更容易且更具可扩展性。
所以我的答案是，在使用 ORM 时，不要疯狂地尝试仅查询所需的字段。。如果您只是在需要的地方手动编写查询，那么只需查询您需要的字段。但既然你在谈论好的架构模式，我认为你没有这样做。
当然也有异常(exception)，例如查询大型数据集以进行报告或迁移。这些将需要独特的优化。
关于php - Mvc 并仅选择需要的字段，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39041907/