假设我有一个包含大量字段的课程Employee。而且我有很多与 db 相关的操作，例如 CRUD、过滤器等。
在 MVC 模式中，所有这些东西都可以放在一类模型部件中。但同样，如果我有很多字段和很多动作怎么办。如何将基本对象人员（字段、基本方法：getter 和 setter、toString 等）和操作正确拆分为类。喜欢Employee 和EmployeeActions？或者有什么最好的方法？需要你的经验）
【问题讨论】：
标签： java model-view-controller model architecture entity
原则上，domain model，例如模型层，例如“模型”，应该分为以下几个部分：
Employee）和value objects。每个实体不仅包含特定数据，而且最重要的是，与其相关的所需行为（仅）。EmployeeMapperInterface）。它们的实现（如EmployeeMapper）不应该是领域层的一部分。数据映射器是负责在实体和数据库（或任何其他持久层）之间传输数据的对象。因此它们是唯一知道如何通过其 API 与数据库通信的组件。例如。它们包含 SQL 语句/调用。此类语句不应以任何方式成为实体的一部分，因为相同的实体可以被多个应用程序使用，并且并非所有应用程序都需要数据库访问权限，或者与另一个应用程序具有相同的数据库访问权限。实体甚至根本不应该知道任何持久性。 EmployeeRepositoryInterface，或EmployeeCollectionInterface，或EmployeesInterface）。它们的实现（如EmployeeRepository，或EmployeeCollection，或Employees）也不应驻留在域层中，而应位于其边界之外。它们是具有向模型组件隐藏持久性类型的作用的构造，并具有两个功能/特征：1）它们将实体从域模型传输到数据映射器，以更新数据库数据和 2）它们存储使用相应的数据映射器从数据库“获取”的实体集合，使其可用于域层。AuthorizationService）。可以有应用程序服务，如果需要，还可以有域服务（由前者使用）。这些服务处理所有其他领域层组件，以便正确响应用户需求。从用户的角度来看，它们是通往领域模型的唯一途径。MailServiceInterface，或PaymentServiceInterface，或PrintingServiceInterface）。它们的实现（如 ExampleMailer、PayPalPayment 或 PdfPrinter）位于域模型之外。资源：
【讨论】：
我认为，如果模型只包含模型类的定义，geters 和 setter 以及所有业务逻辑在单独的类中 - 也许是单独的层，您可以将它们称为 EmployeeActions 或者更好的 EmployeeManager，这样我们保持分离定义的逻辑。 但这仅在您有复杂的应用程序时才需要。有时引入任何额外的层可能会给代码增加不必要的复杂性。
我认为一个好的答案是： https://softwareengineering.stackexchange.com/a/165470
【讨论】：