在MVC分层体系结构中，存储库类是否是业务层的一部分？

Question

假设您有一个具有模型的MVC应用程序，该应用程序由一个实体框架( Entity，EF)表示，它从数据库中“获取”数据，以及实现所有业务逻辑的Controller的操作方法。Controller通过EF从数据库中获取数据。

假设现在您创建了一个位于Controller和Model之间的存储库类。这样你就可以：

1) Controller：实现了大部分业务逻辑；

2) 库类，负责实现简单的业务逻辑，通过方法向应用程序中的每个控制器提供数据，并从EF获取数据；

3) Model：从数据库获取数据并将其提供给Repository类的EF类。

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

1) Controllers：只实现了请求的细化；

2) 业务层：一组类，负责实现大部分业务逻辑，并通过方法向应用程序中的每个控制器提供数据；

3) 存储库类：从EF获取数据，并向业务层公开用于查询数据库的方法；

4) Model：从数据库“获取”数据并将其提供给Repository类的EF类。

我不考虑这意见，因为它是不相关的。我希望有人能为我澄清这一区别。非常感谢

干杯

弗朗西斯科

Answer 1

您为Model提出的定义与MVC模式中术语的传统用法不同--或者至少与马丁·福勒定义的模式不同。

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

控制器的工作是接收用户的输入，并确定如何处理它。

在实际的问题中，关于存储库应该放在哪里，它将在模型中，但封装为数据访问基础结构的一部分(这几乎就是存储库的定义)。

因此，该模型由两个关键部分组成:具有表达业务逻辑的域对象和执行访问数据访问层等功能的服务基础结构。(另一种常见的方法是让模型由服务组成，这些服务并不真正具有丰富的域模型，但仍然包含所有业务逻辑和数据访问)。

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