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

【问题标题】：ASP.Net MVC, ORM and "heavy" objectsASP.Net MVC、ORM 和“重”对象
【发布时间】：2013-02-26 03:53:56
【问题描述】：

我认为这个问题在具有中型模型的 Web 应用程序中很常见。假设我有一个 SportCenter 类，其中包含一个篮球场列表，当显示我仍想显示的篮球场的保留或属性关于它所属的 SportCenter 的信息很少。

我使用 ASP.Net MVC 和 nHibernate 作为数据层，所以我的问题是：是否值得让 nHibernate 加载整个 SportCenter 实例（实际上包含的集合是延迟加载的，但类仍然是“重的”）在一起我的 BasketballField 及其信息只是为了显示运动中心？

另一方面，在 HQL 中构建非常精细的查询让我回到了过去使用手工 SQL 查询的经典 ASP 日...

有什么最佳做法可以推荐吗？

谢谢大家，彼得。

【问题讨论】：

【解决方案1】：

试一试，运行它，分析它。尝试两种方法，并使用类似Red Gate's ANTS Profiler 的配置文件来查看是否存在明显的性能差异。

如果没有太大区别，则使用更具可读性的类 - 使用 SportCenter 类 - 否则，使用 HQL。

恕我直言，OR/Ms 在他们目前的状态下，并不能完全替代 SQL/变体。

【讨论】：

【解决方案2】：

我正在成为命令/查询分离（Greg Young 版本）的坚定信徒，所以我想说，如果您想向用户显示数据（查询），那么您绝对不应该使用您的域模型。当涉及到一个好的域时，Getter 通常是一种反模式。

我目前首选的过程是使用 NHibernate 填充的特定于屏幕的 DTO。这些在从单独的表中驱动时效果最佳，但您可以使用 NHibernates AliasToBeanTransformer 从您的域表中填充。

【讨论】：

但是特定于屏幕的 DTO 使业务层意识到并依赖于 - 至少在语义上 - 在 UI 层上，这是不好的。即使只是为了生成“视图”而从 nHibernate 中编写特定查询也会破坏仅 nHibernate 的数据访问层。无论如何，您的观点听起来很有动机，您对“当涉及到一个好的域时，Getter 通常是一种反模式”是什么意思？谢谢你的回答，彼得。
实际上，您的 DTO 应该存在于单独的查询层中，其唯一的工作是满足客户端查询的需求，在这种情况下，依赖关系（恕我直言）很好。业务层（或者在我的情况下是域层）存在于服务命令。吸气剂的问题是它们很快会导致贫血域。如果每个人都可以获取您的所有数据（应该是私有的），那么他们为什么需要您为他们做任何事情呢？自从我在 Pragmatic Programmers 中读到“告诉，不要问”原则以来，我一直在努力在我的设计中保留更多的面向对象。

【解决方案3】：

如果您从篮球场端查询它，那么每个篮球场可以“获取加入”SportCentre，或者从篮球场端关闭延迟加载（因为每个篮球场只有一个 SportCentre）。

我遇到的主要开销来自 nHibernate 用大量小的延迟加载来破坏数据库，解决方案通常是让它在一次往返中返回所有数据。

【讨论】：

【解决方案4】：

考虑一下 Linq。 NHibernate 支持 Linq。使用 Linq，可以轻松编写返回“部分对象”或您真正想要的任何字段的类型安全查询。

您提出的其他两个选项可能“足够好”并且应该可以工作。

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

查看特定的 DTO 是一种最佳做法，在这里可能很有意义。

【讨论】：

【解决方案5】：

您的问题是您将域暴露给 UI 层。您应该将您的模型与您的视图模型分开。

【讨论】：