我的模特应该住在哪里？ Web 层还是数据层？ (MVC+NHibernate)
我正在使用 MVC、Ninject 和 NHibernate 设置一个 n 层应用程序（我第一次使用这些技术）。 为了清楚起见，这些层是“数据”层、“服务”层和“Web”层（都是单独的项目）。
使用 MVC，您的模型位于“Models”文件夹中。 似乎有必要将我的模型放在这里来创建强类型视图并总体上遵循 MVC 的理念。
然而，对于 NHibernate，我还需要“数据”层中的模型，以便可以进行映射，并且 NHibernate 可以实例化实际对象以返回到服务层。
跨项目复制类并不是很 DRY，并且将它们抽象到自己的库中似乎不太适合 MVC（无论是在实践中还是在理念上）。
有什么想法吗？ 与 MVC 模型相比，您如何构建 O/RM 对象？
I am setting up an n-tier application with MVC, Ninject, and NHibernate (my first using these technologies). For clarity's sake, the tiers are a "Data" tier, a "Services" tier, and a "Web" tier (all are separate projects).
With MVC, you have your models that are in the "Models" folder. It seems necessary to put my models here to create strongly-typed Views and to generally keep with the philosophy of MVC.
However, with NHibernate, I also need my models in the "Data" tier so that the mapping can take place and that NHibernate can instantiate actual objects to return to the services layer.
Duplicating the classes across projects is not very DRY and abstracting them into their own library doesn't seem to play well with MVC (neither in practice nor philosophy).
Any thoughts? How do you structure your O/RM objects vs MVC models?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我将实体框架模型/类保留在数据层中，并使用 MVC 项目的 Models 文件夹来存储表示模型和模型绑定器。
I keep Entity Framework models/classes in the data tier and use the Models folder of the MVC project for presentation models and model binders.
数据模型是它自己的东西。 MVC 中的模型是不同的。 它是您要显示的内容的模型，可能是也可能不是您的数据模型。 您的数据模型可能会超越层，也可能不会。
以标准注册表单为例。 数据模型可能包括用户名、密码和一系列登录历史记录类、指示其处于活动状态的标志以及许多其他内容。 MVC 中的模型可能只关心用户名和密码，并且用户输入密码两次。 您的数据模型真的需要两个密码字段吗？ 不可以。但是 MVC 中的模型可以。 因此，这是两种不同的生物。
The Data Model is it's own thing. The Model in MVC is something different. It's the model of what you're going to display, which may or may not be your Data Model. You're Data Model may transcend layers, or not.
Take for instance the standard sign-up form. The Data Model may include the username, password and an array of login history classes, a flag indicating it's active and much other stuff. The model in MVC, may only really care about username and password, and that the user type the password twice. Does your Data Model really need two password fields? No. However the model in the MVC does. Hence, two different critters.
由于 NHibernate，我将所有模型保留在数据层中。 查看 S#arp 架构，了解保持演示文稿简洁的好方法。 模型不必实际位于您的 Web 项目中，您的视图也可以是强类型的。
I keep all of my models in the data tier because of NHibernate. Take a look at S#arp Architecture for a great way of keeping your presentation clean. Models do not have to be physically located in your web project for your views to be strongly typed.
您对 DRY 原则的理解是正确的。 我将 LINQ-to-SQL 对象与业务对象分开，并且有一些重复，这并不让我感觉良好，但似乎没有简单的解决方法。
我很难做出这个决定，但是我在构建 MVC Storefront 时观看了 Rob Conery 的博客，最后我决定采用这种方式（ORM 对象和业务对象）
You are right about the DRY principle here. I keep my LINQ-to-SQL objects separated from my business objects and I have some duplication and it doesn't make me feel good but it seems there isn't a simple workaround this..
I had a tough time making this decision but I watched Rob Conery's blog while building the MVC Storefront and in the end I decided to go this way (ORM objects AND business objects)
没有一个模型可以是你想要的任何东西。 如果有必要，我仍然会使用演示模型，但我不反对在视图中使用 nhibernate 实体。
使用 NHibernate，您实际上并不需要数据层，因为会话本身就是数据层。
服务层似乎是一个有效的想法，但前提是您计划在该层拥有多个客户端。
否则，我只会有 1 个项目并使用命名空间来分隔我的层。 它构建速度更快并且更容易部署。
No model can be anything you want. I would still use a presentation model if it were necessary but I have no objection to using your nhibernate entities in your views.
With NHibernate you don't really need a Data Tier since the Session itself is the data tier.
The service tier seems like a valid idea but only if you plan on having multiple client for this layer.
Otherwise, I would only have 1 project and use namespaces to separate my layers. It builds faster and is easier to deploy.