我们不需要在MVC3架构中使用DAL Layer吗？

Question

  

可能重复：
  Where to write Database and Business logic in MVC?

我刚刚开始使用MVC3模式。我们如何在MVC3中进行数据访问？我们将'MODEL'设为数据访问层还是我们添加另一个'DAL'图层并从'MODEL'图层调用它？

Answer 1

您的模型应独立于数据访问内容，这将允许您在将来更改DAL策略。

您应该从DAL提供模型，但模型不应该知道它是如何构造的，当然也不应该包含任何特定于数据库的代码。

如果采用我建议的方法，请查看AutoMapper - 一种在DAL和模型类之间映射数据的非常有用的工具。

Answer 2

当我使用上一个MVC3项目时，我对各种样本（例如GeekDinner）的理解是实体框架充当数据访问层。

Answer 3

您的模型可以是直接映射的数据访问对象，但不一定非必须。它们也可以代表您的后端DAL，根据您的要求和项目的使用寿命，它总是更好的选择。

我倾向于为大型项目处理它的方法是使用一个名为Project.Entities的单独命名空间，其中包含我的Entity Framework数据模型。我的Project.Models将包含使用实体作为其数据的后备存储的模型，并提供操作该数据的常用方法（必要时）。它可能不是最好的方法，但提供了最大的灵活性，并坚持将数据模型与后备存储分开，这允许更多的抽象。例如，您始终可以将基础数据层切换到内存存储，而不是实体框架或其他任何DAL。

对于小型/临时/测试项目，我的实体框架数据模型将直接在Project.Models中直接使用，因为它更快，不需要太多考虑。

Answer 4

不，模型不是数据访问。 Model是一组用于保存数据的类，它通常不包含可能用于验证允许指定值的代码。

您可以从控制器访问数据。你这样做完全取决于你和MVC并不关心。

Answer 5

模型是您的视图模型，而不是您的域模型。

如果您想进行DAL活动，我倾向于将其包装在可以注入控制器的存储库/服务中。

这会阻止您的控制器变得臃肿，并且还允许您模拟DAL层以对控制器进行单元测试。