8

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

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

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

据我了解，视图和（也许）控制器位于表示层中。业务层和存储库中的实体（模型），数据层中的 UnitOfWork 和 DbContext。

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

提前致谢！

在此处输入图像描述

4

4 回答 4

3

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

于 2013-09-03T19:24:01.237 回答
3

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

于 2013-09-03T19:27:26.983 回答
2
  • 查看模型/视图/控制器 - 表示层
  • 实体 - 业务层

存储库在数据源层和应用程序的业务层之间进行中介

DbContext代表了 Unit-Of-Work 和 Repository 模式的组合，因此如果您正在实现一个存储库和基于它的工作单元，则可能意味着您应该考虑限制您的抽象。（最后一点可能不适用于您的情况，如果不了解您的设计，我不能说）。

于 2013-09-03T19:50:22.963 回答
2

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

根据您分离代码的方式（听起来您正在使用存储库模式），您可能有一个包含一些业务逻辑的存储库，或者也有一个服务层（我更喜欢 3 层应用程序），其中业务逻辑（主要是） 发生。

我认为你应该考虑视图模型以及你的演示模型的一部分——但是如果你使用 MVC 和数据注释（这对于这项工作来说非常好）来验证你的模型，你只是堆积了一堆业务逻辑进入他们。

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

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

视图 <--仅表示层

控制器 <--仅表示层（在某些情况下可能会以稍微“胖”的控制器告终，例如 .NET 会员登录）

View Models <--Presentation 层，但如果在这里进行验证，业务规则也经常被测试。

服务层 <--如果使用业务层

Repositories <--可能只是数据层，或者业务层的混合。如果您使用存储库模式，请尝试避免直接公开您的 DbSet，因为这会立即破坏您尝试提供的抽象（可能的例外情况，例如 - .Net Membership）

实体 <--数据层，可能还带有业务逻辑，具体取决于您构建应用程序的方式。

*不作为权威

于 2013-09-03T19:31:02.687 回答