我有一个架构问题。我试图建立一个ASP.MVC Web应用程序使用依赖注入来分离数据访问层。问题是 - 模型。解耦ASP.MVC和数据访问层与依赖注入
基本上我有两个解决方案。第一个是MVC Web应用程序，第二个是数据访问层。 DAL具有一些接口，由Entity Framework生成的实现和模型，以及一些其他模型 - 搜索条件和结果。 MVC在使用Ninject注入DAL的基本控制器中有一个属性。
我的担心是 - 我该如何处理模型？
我使用依赖注入的原因是将DAL与主Web应用程序解耦。因此，如果我正确理解DAL应该易于连接/拆卸的想法。但是，如果我在MVC控制器中使用DAL的模型，并且它将完全依赖于DAL中的细微变化。
我在MVC中创建了复制实体框架生成模型的模型，所以我可以在MVC中使用这些MVC模型，并在调用DAL方法之前使用AutoMapper将它们映射到DAL模型，因此仅使用DAL模型在控制器和耦合器中更松散。但它似乎仍然很脏，远非优雅的解决方案。
您认为如何？有什么办法以更聪明的方式处理它？
将您的模型放入一个Common和UI，它们都是UI和DAL引用的。如果你的DAL改变了，你可以让它返回Common中的现有模型，而不需要改变你的UI。或者，如果您更改了用户界面，您的新用户界面可以引用Common.dll并与现有模型一起工作。如果您以后需要添加API，API将只引用Common.dll（或任何您想要调用它）。
编辑：这是假设您不会将EF模型从DAL返回到您的UI。 UI使用视图模型，DAL使用EF模型，两者之间的AutoMapper地图。
你是对的。将数据库模型直接传递给View Engine并不是一个好主意。由于数十个原因（包括性能，潜在的信息泄露，耦合等），不推荐这样做。
我不认为将您的数据库模型映射到视图模型1：1是一个好主意。推荐的方法是让视图模型仅表示您在特定视图中需要的最小值。有一些开销需要不断地将数据模型映射到您的视图模型，以准确提取您在某些视图上需要的内容，但这对于获得清洁和精益视图模型来说是非常必要的。
下面是一些建议如何在ASP.NET MVC使用视图模型：
ASP.NET MVC - How exactly to use View Models
从上面的线程报价克里斯·普拉特：
这是个视图模型进来。MVVM（模型 - 视图 - 视图模型）是一种与MVC有点平行的模式，它认识到单一模式到规则全部方法的固有问题。这里我不会详细讨论，因为MVC不使用这种模式。但是，大多数ASP.NET MVC开发人员已经选择了MVVM的View Model。你实际上最终得到的是一个数据库支持的实体（传统模型），然后通常是许多不同的视图模型，代表不同的状态下的实体。这允许您的模型包含与持久性相关的业务逻辑，而视图模型包含与显示，创建和更新模型相关的业务逻辑。
非常好的主意。总结 - 我试图解耦太多;）。我不知道的事情很简单 - 模型是合同的一部分，是界面的一部分，所以它们不能轻易改变。但有些事情我不确定。请纠正我，如果我错了 - 当我移动模型到普通的我应该 - 在使用EF的情况下 - 重复的实体生成的模型并将它们映射到DAL中，对吗？我的意思是 - DAL接口应该使用通用的模型（即使它只是实体/表模型）。 – Landeeyo 2014-09-25 08:52:31
像下面的答案一样，“有一些开销需要不断地将您的数据模型映射到您的视图模型，以准确提取您在某些视图上需要的内容”。 DAL内部使用EF模型，如用户数据模型，具有后期绑定和负载属性以及虚拟集合，但不包括UI，但UI请求UserEmailViewModel（驻留在Common.dll中），DAL将从其数据模型映射UserEmailViewModel并只返回用户名和电子邮件。所以是的，DAL界面应该返回并在Common.dll中创建模型。它如何映射它们取决于DAL，UI并不在意。 – artm 2014-09-25 09:05:35