c# - 我们不需要 MVC3 架构中的 DAL 层吗？

Question

可能重复：
在 MVC 中哪里编写数据库和业务逻辑？

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

Answer 1

你的模型应该独立于数据访问的东西，这将允许你在未来改变你的 DAL 策略。

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

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

Answer 2

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

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

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

Answer 3

当我处理我的最后一个 MVC3 项目时，我从各种示例（例如 GeekDinner）中了解到实体框架充当数据访问层。

Answer 4

您的模型可以是直接映射的数据访问对象，但不一定必须如此。它们也可以作为后端 DAL 的代理，根据您的要求和项目的寿命，这始终是更好的选择。

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

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

Answer 5

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

您从控制器访问数据。采用哪种方式完全取决于您，而 MVC 并不关心。