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

问题描述

假设我有一个Employee类，其中包含大量字段.而且我有很多与db相关的动作，例如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模式中，所有这些东西都可以放入一类Model部件中.但是同样，如果我有很多领域并且有很多行动该怎么办.如何将基本对象人员(字段，基本方法: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访问.实体甚至根本不应该知道任何持久性.
• 作为可选的抽象层:存储库抽象(例如EmployeeRepositoryInterface或或EmployeesInterface).它们的实现(例如EmployeeRepository或EmployeeCollection或Employees)也不应驻留在域层中，而应位于其边界之外.它们是具有对模型组件隐藏持久性类型的角色的构造，并且具有两个功能/特性:1)将实体从域模型转移到数据映射器，以更新db数据； 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 授权，并根据清洁架构罗伯特·马丁(Robert Martin)
• Sandro Mancuso:交互驱动设计简介
• 坚不可摧的域模型(带有干净代码讨论-继承，多态和&测试.
• 通过以下方法，集思广益，从巨型独石走向清洁建筑维克多·伦特亚(Victor Rentea)

• 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屋！