使用依赖注入解耦 ASP.MVC 和数据访问层答案

【问题标题】：Decoupling ASP.MVC and data access layer with the dependency injection使用依赖注入解耦 ASP.MVC 和数据访问层
【发布时间】：2014-11-19 22:34:01
【问题描述】：

我有一个架构问题。我正在尝试使用依赖注入来构建一个 ASP.MVC Web 应用程序来解耦数据访问层。问题是 - 模型。

基本上我有两个解决方案。第一个是 MVC Web 应用程序，第二个 DLL 是数据访问层。 DAL 有一些接口，它的实现和实体框架生成的模型，还有一些额外的模型——搜索条件和结果。 MVC 在使用 Ninject 注入 DAL 的基本控制器中有一个属性。

我关心的是 - 我应该如何处理模型？

我使用依赖注入的原因是将 DAL 与主 Web 应用程序解耦。因此，如果我正确理解 DAL 应该易于安装/拆卸的想法。但是，如果我在 MVC 控制器和视图中使用 DAL 的模型，它将完全依赖于 DAL 中最轻微的变化。

我在 MVC 中创建了复制实体框架生成的模型的模型，因此我可以在 MVC 中使用这些 MVC 模型，并且在调用 DAL 方法之前，我使用 AutoMapper 将它们映射到 DAL 模型，因此 DAL 模型仅用于控制器和耦合更松散。但它似乎仍然很脏，远非优雅的解决方案。

你怎么看？有没有更聪明的方法来处理它？

【问题讨论】：

标签： asp.net-mvc-4 architecture dependency-injection entity-framework-5 data-access-layer

【解决方案1】：

你是对的。将数据库模型直接传递给视图引擎并不是一个好主意。不推荐这样做，原因有很多（包括性能、潜在的信息泄漏、耦合等）。

我不认为将您的数据库模型以 1:1 映射到视图模型是一个好主意。推荐的方法是让视图模型仅代表您在特定视图中所需的最低限度。不断地将数据模型正确地映射到视图模型以准确提取某些视图所需的内容会产生一些开销，但这对于获得干净和精简的视图模型是必要的。

以下是一些如何在 ASP.NET MVC 中使用视图模型的建议：

ASP.NET MVC - How exactly to use View Models

引用上面帖子中的 Chris Pratt 的话：

这就是视图模型的用武之地。MVVM（模型-视图-视图模型）是一种与 MVC 有点平行的模式，它认识到一个模型来统治所有方法中的固有问题。我不会在这里详细介绍，因为 MVC 不使用这种模式。但是，大多数 ASP.NET MVC 开发人员都选择了 MVVM 的视图模型。您最终得到的是一个数据库支持的实体（传统模型），然后通常是许多不同的视图模型，代表该实体处于各种状态。这允许您的模型包含与持久性相关的业务逻辑，而视图模型包含与显示、创建和更新该模型相关的业务逻辑。

【讨论】：

【解决方案2】：

将您的模型放在 UI 和 DAL 都引用的 Common.dll 中。如果您的 DAL 发生更改，您可以使其返回 Common 中的现有模型，而无需更改您的 UI。或者，如果您更改 UI，您的新 UI 可以仅引用 Common.dll 并使用现有模型。如果您以后需要添加 API，API 将仅引用 Common.dll（或您想调用的任何内容）。

编辑：这是假设您不将 EF 模型从 DAL 返回到您的 UI。 UI 使用视图模型，DAL 使用 EF 模型，AutoMapper 在两者之间映射。

【讨论】：

好主意。结论 - 我试图解耦太多;)。我不知道的事情很简单——模型是合同的一部分，是接口的一部分，所以它们不能轻易改变。但有一点我不确定。如果我错了，请纠正我 - 当我将模型移动到 common 时，我应该 - 在使用 EF 的情况下 - 复制实体生成的模型并将它们映射到 DAL 中，对吗？我的意思是 - DAL 接口应该使用常见的模型（即使它只是实体/表模型）。
就像下面的答案所说“不断地将数据模型正确映射到视图模型以准确提取某些视图所需的内容会产生一些开销”。 DAL 在内部使用 EF 模型，如用户数据模型，具有后期绑定和属性加载，以及虚拟集合等，但 UI 请求 UserEmailViewModel（位于 Common.dll 中），DAL 将从其数据模型映射到 UserEmailViewModel并仅返回用户名和电子邮件。所以是的，DAL 接口应该返回并在 Common.dll 中获取模型。如何映射它们取决于 DAL，UI 不在乎。