一个月前我才发现从 n 层应用的数据访问层直接访问实体/模型的愚蠢行为。在学习 ASP.NET MVC 时阅读了 ViewModels 后，我开始明白，要制作一个真正可扩展的应用程序，UI 层与之交互的模型必须不同于数据访问层可以访问的模型。
但是业务层呢？我的业务层也应该有一组不同的模型吗？对于真正的关注点分离，我是否应该有一组仅与我的业务层相关的特定模型，以免与 DAL 中的任何实体（可能由例如实体框架或 EJB 生成）或将那是矫枉过正吗？
【问题讨论】：
是的，你可以。但是，该特定解决方案会使您的代码复杂化，并导致一堆具有相似属性和数据的 POCO，这是毫无意义的。
然而，主要的一点是，它只是将用于呈现视图的对象与用于表示数据的对象分开。
【讨论】：
模型-视图-视图模型 (MVVM) 的处理方式很好地服务于 ASP.NET MVC。这意味着每个视图都有一个且只有一个 ViewModel，这是一个自定义形状的模型，专用于为该视图提供服务。
例如，如果您有一个需要一些 OrderDetail 和 Customer 数据的 Orders 视图，则创建一个 ViewModel，该视图模型只公开该视图所需的那些实体的数据。 ViewModel 用于将数据聚合在一起来自多个（或一个，根据需要）实体。
您的实体和业务逻辑位于 View/ViewModel 层“之下”，应该不知道它的实现。
【讨论】：