1

我一直在阅读 MVP、MVVM 并在几个实践项目中使用过 asp.net MVC。这些模式大多被称为 UI 模式，这让我有点困惑，因为我曾经认为只有 Views（在 MVC 中）是 UI，而 Model 是数据访问层 + BLL。我的问题是，如果我使用实体框架（edmx）作为我的模型，为什么我需要有一个单独的数据访问层（DAL）以及这个数据访问层在这种情况下实际上会做什么。

4

3 回答 3

1

MVC 和其他模式被认为是 UI/表示模式，因为它们的主要任务是接受来自外部源的请求并显示结果。这些模式的 M 部分通常是指用作帮助填充视图的 DTO（数据传输对象）的简单模型（也称为视图模型）。

业务逻辑，如果它比 CRUD 操作更密集，通常与此分离。这允许不同类型的前端应用程序（这里是 MVC 站点，那里是实际的手机/平板电脑应用程序）以不同的方式与数据交互。

换句话说，MVC 之类的东西实际上只是实际做事的业务逻辑之上的一个皮肤。

您需要问自己将 EF 部分与项目的其余部分分开是否有意义。如果您对数据进行的不仅仅是 CRUD 操作，我会说是的。

于 2012-06-24T16:00:36.087 回答
1

您不需要明确需要单独的 DAL，因为 EF 同时是您的数据访问层和模型。如果您将 POCO 用于您的模型，则需要一个层来处理这些对象的持久性。因此，如果您使用 NH 作为 OR/M，那么您的模型仅由 POCO 对象组成，而 NH 是您的 DAL。通常 NH 隐藏在单独的层中，但这并不是必需的。如果涉及 GUI，您的实体不会直接用于绑定等。MVVM 为其引入了 ViewModel，它充当 GUI 和域模型之间的层，并提供模型所需的所有数据图形用户界面。

于 2012-06-24T16:07:12.697 回答
1

实际上，视图和控制器都处理 UI。基本上，除了模型层之外的所有东西都是针对 UI 的，并且是关于 UI 的。你必须明白，像 REST API 这样的东西也只是一种不同的用户界面。

至于您的研究，我建议您更仔细地研究 Model2 MVC 和 HMVC 作为模式。前者是最接近经典 MVC 的东西，你可以为 web 做。后者有非常有趣的用例并解决了可重用性问题（并且在分布式系统中也有一些潜力）。

现在主要问题。

您将域业务逻辑（在域对象中）与数据访问逻辑（在数据映射器中）分开，因为您获得了以下功能：

  • 代码解耦，关注点分离
  • 独立进行单元测试的能力

基本上，这让您拥有代码库，其中添加特定更改（如添加缓存或模型级别授权检查）不需要您重写整个代码库。

存储机制本身也变得更加灵活。您可以轻松更改特定域对象的数据的存储位置。例如，您可以将用户详细信息和身份验证移动到 noSQL 数据库。这不会对您的业务逻辑的工作方式产生任何影响。当您在较大的团队中工作或维护旧代码时，这将成为一个关键问题，因为很难掌握整个系统并保持这些知识是最新的。

至于数据访问层的作用：它获取域对象（包含域业务逻辑的事物）并从中存储数据或将信息检索到数据源层中。

另外，我建议研究/观看：

免责声明：我的主要语言是 PHP，并且只对 web 上下文中的 MVC 相关模式有经验（主要是使用它的 Model2 变体，因为 web 本身的明显局限性），这塑造了我对MVC 结构的理解。

于 2012-06-24T16:46:33.397 回答