ASP.Net MVC、ORM和“重”对象

Question

我认为这个问题在中等规模的Web应用程序中很常见。比如说，我有一个SportCenter类，它持有一个BasketballField列表，当展示BasketballField的预订或属性信息时，我仍然希望展示一些关于所属SportCenter的信息。

我正在使用ASP.Net MVC和nHibernate作为数据层，因此我的问题是：值得让nHibernate加载整个SportCenter实例（实际上包含的集合是惰性加载的，但仍然很“重”）以及BasketballField及其信息，只为展示SportCenter的几个字段吗？

另一方面，在HQL中构建非常精细的查询会让我回到旧的Classic ASP时代，手工编写SQL查询...

有什么最佳实践可以建议吗？

谢谢大家，Peter.

- Peter

Answer 1

尝试、运行、分析它。两种方式都尝试一下，然后使用像Red Gate's ANTS Profiler这样的分析工具来查看是否有明显的性能差异。

如果差异不是很大，那么就使用更易读的方式——使用SportCenter类；否则就使用HQL。

在我看来，ORM（对象关系映射）目前还不能完全替代SQL/变体。

- Lucas Jones

Answer 2

如果您是从BasketballField端查询它，那么每个BasketballField可以“fetch join”SportCentre，或者关闭BasketballField端的lazy loading（因为每个BasketballField只有一个SportCentre）。

我在使用nHibernate时遇到的主要开销来自于大量小的lazy loads对数据库的负担，解决方案通常是在单次请求中返回所有数据。

- Jon Spokes

Answer 3

我越来越相信命令/查询分离（Greg Young版本），因此如果您想向用户显示数据（查询），绝对不应该使用领域模型。在好的领域中，Getter经常是反面模式。

我目前首选的流程是使用由NHibernate填充的特定于屏幕的DTO。这些DTO最好基于单独的表格驱动，但您也可以使用NHibernates AliasToBeanTransformer从领域表格中填充。

- Shane Courtrille

---

但是屏幕特定的DTO使得业务层意识到并依赖于UI层 - 至少从语义上来说 - 这不是好的做法。甚至为了生成“视图”，从nHibernate编写特定的查询也会破坏仅使用nHibernate的数据访问层。无论如何，你的观点听起来很有动机，你说的“当涉及到一个好的域时，Getter常常是一种反模式”是什么意思？谢谢你的回答，彼得。 - Peter

实际上，您的DTO应该位于单独的查询层中，其唯一工作是满足客户端查询的需求，在这种情况下，依赖关系（在我看来）是良好的。业务层（或者在我的情况下是领域层）存在的目的是为了服务命令。getter的问题在于它们很快会导致贫血的领域模型。如果每个人都可以访问所有数据（应该是私有的），那么他们为什么还需要您为他们做任何事情呢？自从我在《程序员修炼之道》中读到“告诉，不要询问”原则以来，我一直在努力保持更多的面向对象设计。 - Shane Courtrille

Answer 4

考虑使用Linq。NHibernate支持Linq。使用Linq编写类型安全的查询并返回“部分对象”或任何您想要的字段非常容易。

你提出的另外两个选项可能已经足够好并且可以工作。

正如person-b所说，如果您关心性能，请使用分析器。

查看特定的DTO是最佳实践，在这里可能是有意义的。

- Michael Maddox

Answer 5

你的问题在于将领域层暴露给了UI层。你应该将模型与视图模型分离开来。

- epitka