在MVC分层架构中，Repository类是否是业务层的一部分？

假设您有一个MVC应用程序，其中由实体框架（EF）表示的模型可从数据库“获取”数据以及实现所有业务逻辑的动作方法。控制器通过EF从数据库获取数据。在MVC分层架构中，Repository类是否是业务层的一部分？

想象一下，现在创建一个放置在Controller和Model之间的存储库类。这样你有：

1）控制器：实现大部分业务逻辑;

2）库类，负责实现简单的商业逻辑，在应用中通过的方法将数据提供给每一控制器并从EF获取数据;

3）模型：EF类从数据库获取数据并将它们提供给存储库类。

Repository类是业务服务层还是需要在控制器和存储库之间添加业务层？在后一种情况下，我们有：

1）控制器：只实现请求详细说明;

2）业务层：一组负责实施大多数业务逻辑的和每控制器在通过方法的应用提供数据类;

3）库类：从EF获取数据和公开方法的业务层用于查询数据库;

4）型号：EF类，“获取”数据库中的数据并将其提供给库类。

我不认为视图，因为它是不相关的。我希望有人能为我明确这个区别。通过Martin Fowler here定义或者至少模式 - 非常感谢

干杯

弗朗西斯

来源

2011-04-07 CiccioMiami

您所提出的模型和控制器的定义从MVC模式的术语的传统用法不同。

通常它是包含大部分业务逻辑的模型，Controller负责管理视图和模型之间的信息流。若要从福勒的文章引用：

控制器的任务是采取用户的输入，并找出做什么它。

看着就到存储库应放在你的实际问题，这将是模型内，但包裹在您眼前的数据接入基础设施的组成部分（几乎是一个库是什么非常清晰）。

因此，模型由两个关键部分组成 - 具有表达性业务逻辑的域对象和执行诸如访问数据访问层的服务基础结构。（另一种常见方法是让模型由不具备丰富域模型功能的服务组成，但仍包含所有业务逻辑和数据访问）。

最后一个想法是小心过度思考或抽象这些东西 - 保持尽可能简单，只有当您确信它会带来价值时才会为您的架构引入新层。例如 - EF本身可以在大多数情况下执行您的Repository的角色，因此直接使用它不需要存储库层可以删除不必要的抽象。

来源

2011-04-07 15:07:37

其实我感到有点困惑。在许多ASP.NET MVC教程中，控制器是包含具有业务逻辑的方法的组件。我也提出了另一个类似的问题，他们回答说，Repository不能有任何业务逻辑。请你看看[这个问题]（http://stackoverflow.com/questions/5581165/add-simple-business-logic-to-repository-in-aspnet-mvc-3-c）并告诉我什么是正确的方法？谢谢 – CiccioMiami 2011-04-07 15:59:10

@Francesco它当然会有很大的不同，但总的来说，MVC教程忽略了模型，而是将注意力集中在视图和控制器上。这导致了一种误解，即该模型纯粹是数据和轻量级数据传输对象。最佳实践反而认为模型是所有业务逻辑的地方*除了围绕特定视图及其呈现（这是控制器业务逻辑）。至于你的其他问题，我同意，存储库只应该关注抽象数据访问问题，而不是业务逻辑。 – 2011-04-07 22:26:49

@Francesco：根据DDD的书，我认为许多ASP.NET MVC教程中的模型都是ViewModel，它主要用于视图，而不是域模型，我们将把数据和业务逻辑放在一起。 – 2011-04-08 03:43:13

在MVC分层架构中，Repository类是否是业务层的一部分？

回答

相关问题