我一直在阅读有关 MVP、MVVM 的文章，并在几个实践项目中使用过 asp.net MVC。这些模式大多被称为 UI 模式，这让我有点困惑，因为我曾经认为只有 Views（在 MVC 中）是 UI，而 Model 是数据访问层 + BLL。 我的问题是，如果我使用实体框架 (edmx) 作为我的模型，为什么我需要有一个单独的数据访问层 (DAL) 以及这个数据访问层在这种情况下实际上会做什么。
【问题讨论】：
标签： entity-framework model-view-controller design-patterns
实际上，视图和控制器都处理 UI。基本上，除了模型层之外的所有东西都是针对 UI 的，并且是关于 UI 的。而且你必须明白，像 REST API 这样的东西也只是一种不同的用户界面。
至于您的研究，我建议您更深入地了解 Model2 MVC 和 HMVC 作为模式。前者是最接近经典 MVC 的东西，你可以为 web 做。后者有非常有趣的用例并解决了可重用性问题（并且在分布式系统中也有一些潜力）。
现在是主要问题。
您将域业务逻辑（在域对象中）与数据访问逻辑（在数据映射器中）分开，因为您获得了以下功能：
基本上，这让您拥有代码库，其中添加特定更改（如添加缓存或模型级别授权检查）不需要您重写整个代码库。
存储机制本身也变得更加灵活。您可以轻松更改特定域对象的数据的存储位置。例如，您可以将用户详细信息和身份验证移至 noSQL 数据库。这不会对您的业务逻辑的工作方式产生任何影响。当您在较大的团队中工作或维护旧代码时，这将成为一个关键问题，因为很难掌握整个系统并保持这些知识是最新的。
至于数据访问层的作用：它获取域对象（包含域业务逻辑的事物）并从中存储数据或将信息检索到数据源层。
另外，我建议研究/观看：
免责声明：我的主要语言是 PHP，并且只对 web 环境中的 MVC 相关模式有经验（主要是使用它的 Model2 变体，因为web 本身），它塑造了 MVC 结构的my understanding。
【讨论】：
您不需要明确需要单独的 DAL，因为 EF 同时是您的数据访问层和模型。如果您将 POCO 用于您的模型，则需要一个层来处理这些对象的持久性。因此，如果您使用 NH 作为 OR/M，那么您的模型仅由 POCO 对象组成，而 NH 是您的 DAL。通常 NH 隐藏在单独的层中，但这并不是必需的。如果涉及 GUI，您的实体不会直接用于绑定等。MVVM 为其引入了 ViewModel，它充当 GUI 和域模型之间的层，并提供模型所需的所有数据图形用户界面。
【讨论】：
MVC 和其他模式被认为是 UI/表示模式，因为它们的主要任务是接受来自外部源的请求并显示结果。这些模式的 M 部分通常是指用作帮助填充视图的 DTO（数据传输对象）的简单模型（也称为视图模型）。
业务逻辑，如果它比 CRUD 操作更密集，通常会从中分离出来。这允许不同类型的前端应用程序（这里是 MVC 站点，那里是实际的手机/平板电脑应用程序）以不同的方式与数据交互。
换句话说，MVC 之类的东西实际上只是实际执行某些操作的业务逻辑之上的皮肤。
您需要问问自己，将 EF 部分与项目的其余部分分开是否有意义。如果您对数据进行的不仅仅是 CRUD 操作，我会说是的。
【讨论】：