模型/实体和N层应用程序

Question

我一个月前才发现从n层应用程序的数据访问层直接访问实体/模型的愚蠢行为。在研究ASP.NET MVC的同时阅读ViewModels后，我逐渐明白，要创建一个真正可扩展的应用程序，UI层与之交互的模型必须与数据访问层可以访问的模型不同。

但是商业层怎么样？我的业务层也应该有不同的模型集吗？为了真正分离关注点，我是否应该拥有一组仅与我的业务层相关的特定模型，以免混淆DAL中的任何实体（可能由例如实体框架或EJB生成）或者有点矫枉过正？

Answer 1

是的，你可以。但是，该特定解决方案使您的代码复杂化并导致一堆具有类似属性和数据的POCO，这是毫无意义的。

然而，重要的是，它只是将用于渲染视图的对象与用于表示数据的对象分开。

Answer 2

ASP.NET MVC很好地受到了Model-View-ViewModel（MVVM）服务方式的支持。这意味着每个视图都只有一个ViewModel，这是一个专门为该视图提供服务的自定义模型。

例如，如果您有一个需要一些OrderDetail和Customer数据的Orders视图，请创建一个ViewModel，它只公开来自该视图所需的那些实体的数据。 ViewModel用于将数据聚合在一起来自多个（或一个，必要的）实体。

您的实体和业务逻辑位于View / ViewModel层的“下”，应该不知道它的实现。