使用依赖注入将ASP.MVC和数据访问层分离

Question

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

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

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

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

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

你怎么看？有没有办法以更聪明的方式处理它？<​​/ p>

Answer 1

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

我不认为将您的DB模型映射到View Models 1：1是一个好主意。建议的方法是让视图模型仅代表特定视图中所需的最小值。有一些开销可以不断地将您的数据模型正确地映射到您的视图模型，以准确提取您在某些视图上所需的内容，但这对于获得干净且精益的视图模型来说是必要的。

以下是如何在ASP.NET MVC中使用View Models的一些建议：

ASP.NET MVC - How exactly to use View Models

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

  

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

Answer 2

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

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