ASP.NET MVC，图层，模型，存储库等

Question

在阅读一篇名为Layered Application Guidelines（http://msdn.microsoft.com/en-us/library/ee658109.aspx）的文章后，我有一些问题。

例如，我有一个ASP.NET MVC应用程序。在我的应用程序中，我有一些实体（模型），存储库，UnitOfWork和DbContext。还有一些视图和控制器。

如何根据上面的文章将它们分成几层？

据我所知，视图和（可能）控制器驻留在表示层中。业务层和存储库中的实体（模型），数据层中的UnitOfWork和DbContext。

我是对还是错？我非常不确定。

提前致谢！

Answer 1

视图和控制器应驻留在表示层中。您的模型也应位于表示层中。模型反映了仅用于演示的视图模型。实体应代表数据，不应发送到视图。在稍后的演示中，应该从实体填充模型。你的DbContext和UnitOfWork应该在数据层中是正确的。

Answer 2

图层分离的方式取决于应用程序的范围。对于一个小的，区域可能就足够了。对于较大的项目或可能变大的项目，您应该考虑为每个层创建单独的解决方案。这被称为n层方法，在查看http://prodinner.codeplex.com/处的优秀示例时可以看到。

Answer 3

实体框架实体（以及框架）是您的数据层。在许多应用程序中，它们也成为业务层的一部分 - 这是否有用是值得商榷的（我个人不喜欢这样，但当你用存储库模型抽象它时，有一个很好的论据，你输了EF提供的一些好处。

根据您分离代码的方式（听起来您使用的是存储库模式），您可能拥有包含某些业务逻辑的存储库，或者也有业务层（我对3层应用程序的偏好）逻辑（大多数）发生。

我认为你应该考虑使用View Models以及你的演示模型的一部分 - 但是如果你使用MVC和数据注释（这个工作非常好）来验证你的模型你刚刚堆了一堆他们的业务逻辑。

防止业务逻辑蔓延的最重要的地方是您的表示层，最重要的是您的视图和控制器。构建应用程序其余部分的方法在很大程度上取决于您选择的框架，应用程序的规模以及应用程序的部署结构。

所以要尽可能清楚这就是我做 *：

观看次数＆lt; - 仅限展示图层

控制器＆lt; - 仅限表示层（在某些情况下可能最终会出现'胖'控制器，例如.NET会员登录）

查看模型＆lt; - 表示层，但如果在此处进行验证，通常也会测试业务规则。

服务层＆lt; - 业务层（如果使用）

存储库＆lt; - 可能只是数据层，或者是业务层的混合。如果您执行存储库模式尝试并避免直接暴露您的DbSet，因为这会立即击败您尝试提供的抽象（可能的例外情况，例如 - .Net成员资格）

实体＆lt; - 数据层，可能还包含业务逻辑，具体取决于您构建应用程序的方式。

* 不被视为权威

Answer 4

• 查看模型/视图/控制器 - 表示层
• 实体 - 业务层

The repository mediates between the data source layer and the business layers of the application

DbContext Represents a combination of the Unit-Of-Work and Repository patterns，因此，如果您在其上实现存储库和工作单元，则可能意味着您应该考虑limit your abstractions。 （最后一点可能不适用于您的情况，如果不了解您的设计，我不能说。）