在MVC模式中将模型和动作划分为类的最佳方法是什么 [英] What's the best approach to divide model and actions into classes in MVC pattern

问题描述

假设我有一个包含大量字段的类 Employee.我有很多与数据库相关的操作，比如 CRUD、过滤器等.

Let's say I have a class Employee with a huge amount of fields. And I have a lot of actions related to db with it like CRUD, filter etc.

在 MVC 模式中，所有这些东西都可以放在一类模型部分中.但同样，如果我有很多领域和很多行动怎么办.如何将基本对象人员(字段、基本方法:getter & setter、toString 等)和操作正确拆分为类.像 Employee 和 EmployeeActions 吗?或者任何最好的方法?需要你的经验)

In MVC pattern all of these stuff could be placed into one class of Model part. But again, what if I have a lot of fields and a lot of actions. How to properly split to classes the basic object staff (fields, basic methods: getters & setters, toString etc.) and the actions. Like Employee and EmployeeActions? Or any best approach? Need your experience)

推荐答案

原则上，域模型，例如模型层，例如模型"，应该分为以下几个部分:

In principle, the domain model, e.g. the model layer, e.g. the "model", should be divided into the following components:

• 实体，例如域对象(例如您的 Employee)和 值对象.每个实体不仅包含特定数据，而且最重要的是，包含与之相关的所需行为(仅).
• 数据映射器抽象(如EmployeeMapperInterface).它们的实现(如 EmployeeMapper)不应该是域层的一部分.数据映射器是负责在实体和数据库(或任何其他持久层)之间传输数据的对象.因此，它们是唯一知道如何通过其 API 与数据库进行通信的组件.例如.它们包含 SQL 语句/调用.此类语句不应以任何方式成为实体的一部分，因为多个应用程序可以使用相同的实体，并且并非所有应用程序都需要 db 访问权限，或者与另一个应用程序具有相同的 db 访问权限.实体甚至根本不应该知道任何持久性.
• 作为可选的抽象层:repository 抽象(如 EmployeeRepositoryInterface，或 EmployeeCollectionInterface，或 EmployeesInterface).它们的实现(如 EmployeeRepository 或 EmployeeCollection 或 Employees)也不应位于域层中，而应位于其边界之外.它们是具有对模型组件隐藏持久性类型的作用的构造，具有两个功能/特征:1) 它们将实体从域模型传输到数据映射器，以更新数据库数据和 2) 它们存储使用相应的数据映射器从数据库获取"的实体集合，使其可用于域层.
• 服务，作为服务层的一部分(如AuthorizationService).可以有应用程序服务，如果需要，还有域服务(由前者使用).这些服务处理所有其他领域层组件，以便正确响应用户需求.从用户的角度来看，它们是域模型的唯一入口.
• 外部服务的抽象(如MailServiceInterface，或PaymentServiceInterface，或PrintingServiceInterface).它们的实现(如 ExampleMailer、PayPalPayment 或 PdfPrinter)位于域模型之外.

• Entities, e.g. domain objects (like your Employee) and value objects. Each of the entities contains not only the specific data, but, most important, the required behaviour related to it (ONLY).
• Data mappers abstractions (like EmployeeMapperInterface). Their implementation (like EmployeeMapper) should NOT be part of the domain layer. The data mappers are the objects responsible with the transfer of data between the entities and database (or any other persistence layer). So they are the only components which know how to communicate with the database through its API. E.g. they contain the SQL statements/calls. Such statements should NOT be in any way part of the entities, since the same entities can be used by multiple applications, and not all applications require db access, or the same db access as the other. The entities should not even know about any persistence at all.
• As an optional abstraction layer: repository abstractions (like EmployeeRepositoryInterface, or EmployeeCollectionInterface, or EmployeesInterface). Their implementation (like EmployeeRepository, or EmployeeCollection, or Employees) should also NOT reside in the domain layer, but outside its boundaries. They are constructs having the role of hiding the type of persistence from the model components and have two functionalities/characteristics: 1) They transfer the entities from the domain model to the data mappers, in order to update the db data and 2) They store the collection of entities "fetched" from the db using the corresponding data mappers, making it available to the domain layer.
• Services, as part of the service layer (like AuthorizationService). There can be application services and, if needed, domain services (which are used by the former ones). The services handle all other domain layer components in order to properly respond to the user requirements. From the user's point of view, they are the only gateway to the domain model.
• Abstractions of external services (like MailServiceInterface, or PaymentServiceInterface, or PrintingServiceInterface). Their implementations (like ExampleMailer, or PayPalPayment, or PdfPrinter) lie outside the domain model.

资源:

• 应该如何在 MVC 中构建模型?
• 主题演讲:失落岁月的建筑 - 给出的演示文稿由 Robert Martin 提供，根据 Creative Commons Attribution ShareAlike 3.0.
• 简洁架构作者:罗伯特·马丁
• Sandro Mancuso:交互驱动设计简介
• 牢不可破的域模型(使用幻灯片).附加内容:The Clean Code Talks - 继承、多态性，&测试.
• 通过头脑风暴从单体应用到干净的架构维克多·伦蒂亚

• How should a model be structured in MVC?
• Keynote: Architecture the Lost Years - Presentation given by Robert Martin, licensed under a Creative Commons Attribution ShareAlike 3.0.
• The Clean Architecture by Robert Martin
• Sandro Mancuso : An introduction to interaction-driven design
• Unbreakable Domain Models (with slides). Additional to it: The Clean Code Talks - Inheritance, Polymorphism, & Testing.
• Brainstorming your way from a Monolith to a Clean Architecture by Victor Rentea

这篇关于在MVC模式中将模型和动作划分为类的最佳方法是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！