MVC 层和 DAL 和数据层答案

【问题标题】：MVC layers and DAL & Data layersMVC 层和 DAL 和数据层
【发布时间】：2014-04-08 15:22:01
【问题描述】：

我一直在开发一个多层 MVC 应用程序，现在回顾一下我到目前为止所做的工作。尤其是现在我已经返回并再次阅读了有关多层/层的大量信息（那里有大量信息，但没有真正的一致性或标准），我现在正在质疑我的数据层。

我强烈怀疑我没有正确地实现它（符合良好的设计）并且可能已经偏离正题。这是我所做的：

网页界面

BLL

数据

...

退后一步，重新审视，这是我所看到的，也是我所质疑的：

在 BLL 中，此处的 EF 代码看起来不正确。它应该在数据层。有人可以确认一下吗？
我的数据层（即数据项目）包含上下文类和域模型。我读过人们将他们的数据层分为 a) DAL 和 b) 模型。因此，我猜 DAL 层将包含上下文类和数据 (EF) 代码，而模型层将仅包含域模型。这最终会使您总共有 4 层。可能是太过分了还是设计不错？
在哪里使用 AutoMapper 进行 EF 到 ViewModel 映射的任何偏好？我目前正在 Web 层中进行映射，但怀疑它在 BLL 中可能更整洁。有些映射只能在 Web 层完成，例如下拉列表的 SelectListItem。

【问题讨论】：

【解决方案1】：

阅读了很多，这篇文章与那里的很多信息一致，并回答了我的大部分问题：

EF 代码应该在 DAL 中，而不是 BLL。
将模型（从 DAL 中移出）移到它自己的程序集中。现在我的数据层有两个程序集：DAL 和模型。这可能归结为个人喜好。另外，我希望 Web 层仅引用模型程序集，而不是 DAL。
我怀疑我可能在 Web 和 BLL 层中都有映射。尚未确认，当我开始处理这个问题时。

如果有人有更好更详细的答案，我很乐意接受，否则本文似乎回答了很多与层相关的问题。

【讨论】：

【解决方案2】：

我认为使用 ORM（尤其是在代码优先的方法中）确实使单独的 DAL 项目变得很麻烦（说真的，与纯 ADO.NET DataReader 相比，ORM 中的 DA 部分微不足道）。相反，我更喜欢创建一个关于数据持久性的Prj.Domain。基本上是DAL+Model 层或您的组合。

Prj.WebUI 将拥有自己的模型（更好地命名为 ViewModels），它们仅用作在 Views 中处理域数据的便捷方式。

从 MVC 的角度来看，Prj.Domain 是一个模型，Prj.WebUI 是一个视图和控制器。

【讨论】：