在MVC分层体系结构中，存储库类是否属于业务层? [英] In a MVC tiered architecture a Repository class is part of the Business layer or not?
问题描述
假设您有一个MVC应用程序，其中的 Model 由实体框架(EF)表示，该实体框架从数据库中获取"数据，而 Controller 的操作方法实现所有业务逻辑. Controller通过EF从数据库中获取数据.
想象一下，现在您创建一个放置在Controller和Model之间的 Repository类.通过这种方式，您可以:
1)控制器:实现大多数业务逻辑；
2)一个存储库类，负责实现简单的业务逻辑，通过方法向应用程序中的每个 Controller 提供数据，并从EF中获取数据；
3)模型:用于从数据库获取数据并将其提供给 Repository类的EF类.
存储库类是业务服务层还是需要在控制器和存储库之间添加业务层?在后一种情况下，我们有:
1)控制器:仅实现请求的详细说明；
2)业务层:一组负责实现大多数业务逻辑并通过方法将数据提供给应用程序中每个 Controller 的类；
3)存储库类:从EF获取数据，并将方法公开给业务层以查询数据库；
4)模型:用于从数据库中获取"数据并将其提供给 Repository类的EF类.
我不考虑该视图，因为它不相关.我希望有人可以为我阐明这一区别.非常感谢
欢呼
弗朗切斯科
您为Model和Controller提出的定义不同于MVC模式中术语的传统用法-或至少是由
通常，模型包含大多数业务逻辑，而控制器负责管理视图和模型之间的信息流.引用福勒的文章:
控制器的工作是 用户的输入并弄清楚该怎么做
考虑有关存储库放置位置的实际问题，该问题将在模型内，但封装为数据访问基础结构的一部分(这几乎就是存储库的定义). /p>
因此，该模型由两个关键部分组成-具有表达业务逻辑的域对象，以及执行诸如访问数据访问层之类的服务的基础结构. (另一种常见方法是让模型由不真正具有丰富域模型的服务组成，但是仍然包含所有业务逻辑和数据访问权限.)
最后一个想法是仔细考虑或抽象化这些内容-使其尽可能简单，并且仅在确定它将带来价值时才在体系结构中引入新的层.例如-EF本身在大多数情况下都可以充当存储库的角色，因此在没有存储库层的情况下直接使用EF可以删除不必要的抽象.
suppose you have an MVC application with the Model represented by an Entity Framework (EF) that "gets" data from a database and the action methods of the Controller that implements all the business logic. The Controller gets data from the database through the EF.
Imagine that now you create a Repository class that is placed between Controller and Model. This way you have:
1) Controller: implements most of the business logic;
2) A Repository class, responsible to implement simple business logic, provide data to every Controller in the application through methods and get data from the EF;
3) Model: EF classes that gets data from the database and provide them to the Repository class.
Is the Repository class the business service layer or there is the need to add a business layer placed between controllers and repository? In this latter situation we have:
1) Controllers: implements just the request elaboration;
2) Business layer: a set of classes responsible to implement most of the business logic and provide data to every Controller in the application through methods;
3) A Repository class: gets data from the EF and expose methods to the Business layer for querying the database;
4) Model: EF classes that "get" data from the database and provide them to the Repository class.
I do not consider the View because it is not relevant. I hope somebody can make clear for me this distinction. Many thanks
Cheers
Francesco
The definitions you have proposed for Model and Controller differ from the traditional usages of the terms in the MVC pattern - or at least, the pattern as defined by Martin Fowler here.
Usually it is the Model that contains most of the business logic, and the Controller is responsible for managing the flow of information between the View and the Model. To quote from Fowler's article:
The controller's job is to take the user's input and figure out what to do with it.
Looking at your actual question with regard to where a Repository should be placed, it would be within the Model, but encapsulated away as part of your data access infrastructure (that is almost the very definition of what a Repository is).
So the Model becomes made up of two key parts - Domain objects which have expressive business logic, and service infrastructure that does things like accessing the data access layer. (Another common approach is to have the Model made up of services which don't really feature a rich domain model, but still this contains all business logic and data access).
One last thought is be careful about over thinking or abstracting this stuff - keep it as simple as possible and only introduce a new layer to your architecture when you are sure it will give value. For example - EF itself can perform the role of your Repository in most scenarios, so using it directly without the repository layer can remove an unnecessary abstraction.
这篇关于在MVC分层体系结构中，存储库类是否属于业务层?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
