我的模型应该住在哪里？ Web 层还是数据层？ (MVC + NHibernate)答案

【问题标题】：Where should my models live? Web tier or Data tier? (MVC + NHibernate)我的模型应该住在哪里？ Web 层还是数据层？ (MVC + NHibernate)
【发布时间】：2010-10-07 12:03:16
【问题描述】：

我正在使用 MVC、Ninject 和 NHibernate 设置一个 n 层应用程序（我第一次使用这些技术）。为了清楚起见，这些层是“数据”层、“服务”层和“Web”层（都是单独的项目）。

使用 MVC，您的模型位于“模型”文件夹中。似乎有必要将我的模型放在这里以创建强类型视图并通常与 MVC 哲学保持一致。

但是，对于 NHibernate，我还需要“数据”层中的模型，以便可以进行映射，并且 NHibernate 可以实例化实际对象以返回到服务层。

跨项目复制类不是很干，将它们抽象到自己的库中似乎不能很好地与 MVC 配合使用（无论是在实践中还是在哲学上）。

有什么想法吗？您如何构建 O/RM 对象与 MVC 模型？

【问题讨论】：

我很好奇 2 年的流逝是如何证明的，（提炼、强化等）这个问题。 MVC3 会改变等式吗？我正准备在传统 nH 数据层到 EF 之间创建混合以支持脚手架。今天混合 NH 和 EF 时，VS 项目的分组是什么？ - 谢谢
现在怎么样！？自提出上述问题以来已经快 2 年了？

标签： asp.net-mvc nhibernate design-patterns n-tier-architecture

【解决方案1】：

数据模型是它自己的东西。 MVC 中的模型有所不同。它是您要显示的模型，可能是也可能不是您的数据模型。您的数据模型可能会超越层级，也可能不会。
以标准的注册表单为例。数据模型可能包括用户名、密码和登录历史类数组、指示它处于活动状态的标志以及许多其他内容。 MVC 中的模型，可能只关心用户名和密码，并且用户输入两次密码。您的数据模型真的需要两个密码字段吗？不，但是 MVC 中的模型可以。因此，两种不同的小动物。

【讨论】：

好的。因此，似乎共识是将表示模型保留在 Web 层，将我的领域模型保留在数据层。那么我的服务层应该返回到 Web 层什么？它应该知道演示模型吗？还是应该返回领域模型？
服务层应该返回数据模型。或者，问问自己......如果我有不同的接口访问我的服务会发生什么？您的服务层对前端的了解越少，从长远来看，您的情况就越好。

【解决方案2】：

您在这里的 DRY 原则是正确的。我将我的 LINQ-to-SQL 对象与我的业务对象分开，并且我有一些重复，这并没有让我感觉良好，但似乎没有一个简单的解决方法..

我很难做出这个决定，但我在构建 MVC 店面时看了 Rob Conery 的博客，最后我决定走这条路（ORM 对象和业务对象）

【讨论】：

【解决方案3】：

使用 MVC，您的模型可以位于“模型”文件夹中。它似乎有必要把我的模型放在这里创建强类型视图并大体上与哲学保持一致 MVC。

没有模型可以是你想要的任何东西。如果有必要，我仍然会使用演示模型，但我不反对在您的视图中使用您的休眠实体。

使用 NHibernate，您实际上并不需要数据层，因为 Session 本身就是数据层。

服务层似乎是一个有效的想法，但前提是您计划为该层设置多个客户端。

否则，我将只有 1 个项目并使用命名空间来分隔我的层。它构建速度更快，更易于部署。

【讨论】：

“使用 NHibernate，您实际上并不需要数据层，因为 Session 本身就是数据层。”为了实现存储库模式，我将数据层抽象化。这样，我的服务是针对一个接口进行编程的，并且数据层很容易互换（即切换 O/RM）。
然后您可以将您的实体放入核心库中，然后将您的存储库与您的服务放在一起。存储库就是服务。

【解决方案4】：

由于 NHibernate，我将所有模型都保存在数据层中。查看S#arp Architecture 以了解保持演示文稿整洁的好方法。模型不必物理地位于您的 Web 项目中，您的视图也可以被强类型化。

【讨论】：

【解决方案5】：

我将实体框架模型/类保留在数据层中，并将 MVC 项目的 Models 文件夹用于表示模型和模型绑定器。

【讨论】：

好的。因此，似乎共识是将表示模型保留在 Web 层，将我的领域模型保留在数据层。那么我的服务层应该返回到 Web 层什么？它应该知道演示模型吗？还是应该返回领域模型？
不，我认为服务不应该知道演示模型。实际上，服务可能无法知道所需的每一种可能的表示模型。该服务应返回传输对象，可以是实体类型。 Web 层可以将其变为演示模型。
这是有道理的。尽管如此，领域模型到表示模型的这种映射似乎并不是很干，尤其是当两个模型相似时。
他们不一样。考虑：PM 针对数据绑定和用户语言进行了优化。它独立存在于视图/动作上。 DM 已针对与域的其余部分的兼容性进行了优化。 LINQ 可以轻松转换它们。
+1 这很糟糕，但这是正确的方法。在 RoR 世界中，我们通常只有一个模型（而不是两个），事情很快就会变得一团糟。