Will the logic be written to the model using the php framework?

Will the logic be written to the model using the php framework? Or is the model only used to add, delete, and modify data? Where do you write the logic in a simple mvc framework? Controller? Or do you have a logic layer? Will the logic be written to the model using the php framework?

Or is the model only used to add, delete, and modify data?

Where do you write the logic in a simple mvc framework? Controller?

Or do you have a logic layer?

Reply content:

Will the logic be written to the model using the php framework?

Or is the model only used to add, delete, and modify data?

Where do you write the logic in a simple mvc framework? Controller?

Or do you have a logic layer?

I support encapsulating the business logic in the Model. It is best to convert and organize data only in the Controller (or Action, make sure that you do not directly access the data in GET, POST, or SESSION in the Model. All required data is passed into the Model through method parameters or instantiation. In this way, the code is clean and convenient for testing, when you need to write a server-side batch maintenance program, you can still call the Model to obtain and write business data.

At the same time, I agree with @ Airy's practice.

I generally write the logic related to the view to the Controller. For example, different pages are displayed based on the logon status. The logic related to the data is written to the Model.

I am currently: Model: business logic Contrller: interface logic + basic data verification

However, it is found that the business logic is written into the Model, resulting in a very bloated Model, coupled with a variety of infrastructure, third-party Api, and so on, which makes maintenance very inconvenient. We plan to reconstruct and separate the business layer, place the interaction logic between the Model and Model, the Model and other components, and handle exceptions. Make the Model only responsible for data verification and CRUD.

I added a business layer in the middle. The controller only performs input and output operations without business logic. The business logic is placed at the business layer for processing to improve code availability. The model corresponds to the table one by one and only performs single table queries or associated queries.

This involves an issue of object-oriented design. Robert C. Martin puts forward the SOLID principle in the object-oriented design principle. For details, refer to this link in Wikipedia.

Then, the controller is used to schedule views and business modules. Therefore, the Controller should not include the processing functions of business logic according to the single function principle, that is to say, the business logic should not be processed in the Controller part.

Should the business logic be processed in the Model part? When we observe the concept of Model, we will find that this concept is vague. Because the processing of business logic is divided into at least two parts: the first part, data access; the second part, logical operation. According to my understanding, I personally think that the work of the Model layer lies in the implementation of business logic, rather than data access.

We thought about this problem in turn. If we coupled the business logic and data access in a class, what would happen? The obvious problem is that when our data sources change and adjust in the future architecture, we must modify the Model class to adapt to this change, this should violate the principle of opening/closing and the single functional principle. Therefore, it is reasonable to encapsulate data access into another class separately.

When we design a program, in addition to the basic functions, we must also consider the maintainability of the Code and the scalability of the program. Therefore, the program must be "highly cohesive, low coupling ", ideally, when the demand and architecture change, we should not modify the established code, but add new code to reflect the changes the system is facing; between different modules, the interface programming is used to call each other, while the internal implementation of the closed module is implemented.

Therefore, in general, the Controller only processes views and Model calls independently and relies on interfaces for data transmission. The internal implementation of Views and models should be closed to the Controller. Among the MVC design principles, Thin Controller Fat Model is one principle that is widely recognized. In practice, the processing results of some business logic may be processed by resident processes and scheduled tasks, while the Controller only needs to communicate with the static cache to quickly respond. Therefore, business logic processing is a separate system.

Of course, system hierarchy and decoupling will bring additional complexity and burden to object management and design. The MVC pattern is not the best pattern suitable for all situations. For small and medium systems, if the business logic is not complex, the Model1 pattern is used for system design, that is, a front-end display system and a back-end data operating system. For systems that require long-term dynamic maintenance, service expansion, and flexible configuration of system hardware and software resources, full encapsulation decoupling is required to isolate the problem.

I am basically the same as the previous ones. The only difference may be that the model layer only writes the logic code for a data table, the complex business logic designed for multiple tables is written at the additional business layer.

Our new employees usually write the logic in the Controller, and the Model has nothing to do.

Therefore, the entry Instructions stipulate that the business logic should be written in the Model.

Because: In the Controller, some business logic encoding is repeated.

For example, a patient's bed change may appear in multiple controllers: new admission, old person bed change, and discharged hospital, but the code should only be written in the patient or bed Model.

Reference text
Complex business logic involving multiple tables is written at the additional business layer.

I still think this should be written in the Model. Because multiple models are involved, only a suitable Model can be selected to write code, and other models can be called.

I don't know if there is a better design scheme.