What's the best approach to divide model and actions into classes in MVC pattern

Question

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.

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)

Answer 1

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

• 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.

Resources:

• 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

Answer 2

I think that normaly will be if the Model contains only the definition of Model classes with geters and setters and all Business Logic in separate classes - maybe separate layer, you can call them EmployeeActions or maybe better EmployeeManager in such way we keep separated logic from definition. But this is only required when you have complex application. Sometimes introducing any additional layers may add unwanted complexity to the code.

I think a good answer is: https://softwareengineering.stackexchange.com/a/165470