Business logic on the controller layer good or model layer good

Always feel that the model layer is only used to manipulate data, a lot of business processing in the controller, there is a claim that business logic is more suitable for the model layer, do not know which processing better!
Look at the tp5.0, as if the business logic in the model, and then read some stickers, many say business logic in the model better.
Links: https://ruby-china.org/topics/19292

The business logic put in the model has a problem: a lot of times a business logic needs multiple model mates or calls, such as Ci,model and model between the call is more difficult, and model call model always feel bad!

Read this answer:
In the model layer, if more than one model is required, the controller is called, the interface granularity of the model is done, and the controller is only responsible for invoking several model communications.

Think the business logic in the model is better: controller to handle accept parameters, pass parameters, including from the front end, to the front end, also including from the model to take the return value, to the model parameter, so the controller is very clear to do one thing (take, give, almost is the route, Logic of the model).

Thanks to many people for their answers, MVC has a deeper understanding!

Reply content:

Always feel that the model layer is only used to manipulate data, a lot of business processing in the controller, there is a claim that business logic is more suitable for the model layer, do not know which processing better!
Look at the tp5.0, as if the business logic in the model, and then read some stickers, many say business logic in the model better.
Links: https://ruby-china.org/topics/19292

The business logic put in the model has a problem: a lot of times a business logic needs multiple model mates or calls, such as Ci,model and model between the call is more difficult, and model call model always feel bad!

Read this answer:
In the model layer, if more than one model is required, the controller is called, the interface granularity of the model is done, and the controller is only responsible for invoking several model communications.

Think the business logic in the model is better: controller to handle accept parameters, pass parameters, including from the front end, to the front end, also including from the model to take the return value, to the model parameter, so the controller is very clear to do one thing (take, give, almost is the route, Logic of the model).

Thanks to many people for their answers, MVC has a deeper understanding!

In the model layer, if more than one model is required, the controller is called, the interface granularity of the model is done, and the controller is only responsible for invoking several model communications.

I put it in Repositories,model only ORM associations and SQL queries.
The Controller only processes requests (the requested data is verified) and jumps.
The frame is laravel (see TP Many are written on the C layer).

You can say why, but MVC is a tried-and-tested architecture model, and the responsibilities of its different components are fairly clear, so refer to the description of MVC in some of the architectural pattern-related books, and see what they consider when dividing their duties:

Excerpt from the following text, translated from "Pattern-oriented software ARCHITECTURE"

Introduction to Patterns

The MVC pattern divides an interactive program into three components. The Model contains the core functions and data. View displays information to the user. The Controller processes the user's input. All View and Controller collaboration forms the user interface. There is also a "change notification mechanism" (free translation, which refers to the availability of the subscription pattern, the Observer pattern, when implemented) to ensure consistency between the UI and model.

An environment suitable for applying this pattern:

Interactive program with flexible human-computer interface.

The problem solved

Here are a few points to summarize:

1. User interface is usually very easy to change (new features, customer changes, etc.)

2. Interface often needs to provide a variety of different ways to use the same function (right mouse button, menu bar, shortcut keys, floating windows)

3. It is often very expensive and difficult to maintain a tightly integrated interface and function, and it is difficult to achieve the desired flexibility (requiring the same data to be displayed in two different icons, making it easy to make changes to the user interface or even at runtime).

Post-Application effects

Advantage

1. the same Model can correspond to multiple View MVC separates the model and UI components strictly, so for a model, you can have multiple different View corresponding to it. At run time, multiple View can even be turned on at the same time, or turned off dynamically.

2. View can synchronize updates Model "Change notification mechanism" can ensure that the model changes, the relevant interface can be timely response.

3. "Pluggable" View and controller MVC's three conceptual distinctions allow you to replace the View and Controller components that correspond to the Model, even at run time.

4. Because the Model part is completely unrelated to the UI-related code, you want to port an MVC program to a new platform without having to change the core functionality part, just rewrite the View and Controller for the new platform.

5. Provides the possibility for the "framework" to be generated, and some application frameworks can be built on this pattern.

Defect (meow one eye on the line)

1. Added complexity, in some cases MVC is not necessarily the best way to implement interactive programs.

2. Don't meow, don't bother to turn over, this part of the content and now known MVC has been a little far away from the

Light pull away before hurriedly finish ...

Although the general public's understanding of MVC has changed a lot (the book is fast catching up with my age), I can see from the front that it consistent's core goal: Decoupling "Model" and "View & Controller"

Features and data are thrown into Model, View and Controller form the UI. This is the result of the rules that have been summed up in practical experience.

Why to separate is the focus, now the interface of the system with respect to the system function, data is too unstable, separate them, can ensure that the frequent changes in the interface does not affect the stability of the functional data. This gives the system a lot of superior properties.

So let's just ask a few questions before deciding where to write a part of the code:

1. If the boss says tomorrow that the front end of the system is to be replaced by the browser, can it remain in the part of the server that does not change?

2. 1 is not sure, consider this (kill the Boss is not an option): If the boss the day after tomorrow said customers like Retro, not mobile app, to use the command line to operate everything. Does this part of the code need to be implemented?

If so, it should be attributed to the model category, but it can still be refined (as other answers say, the model is divided into multiple parts, each with a focus).

Architecture provides an excellent starting point, but is never the focus Point of the design, and the process of project evolution is seen as a recruit. Or you can anticipate problems, advance prevention, which is the value of experienced people, need to accumulate gradually.

Build a service layer again

The standard MVC pattern
Business logic put model
Simple call to Integrated controller
View Display Drop view

Actual development according to the actual situation change

PS: I don't know why so many people say controller

Feelings your business logic is put in the controller? That's too confusing.

TP has a logical layer ' logic '. Not by default, added manually.
Controller for external use
Logic with logical
Model for data processing

QI, no worries.

can give you reference under, now do the project mode, hope to have help to you! With the tp3.2.3 version, the approximate structure of the project is this:

1. Model layer: Mainly the operation of some databases;

2. Logic layer: We put the business logic into this layer for unified processing, through the way of transaction management, involving multi-table operation problem, so the whole is more clear; here, logic invokes the model's single data operation;

3. Controller layer: Receive and process data, a single business, directly call model data operations can be completed, involving multiple data table operations, call the logic layer

It must be a controller!

Controller is more appropriate.

Of course it was written in the controller. Use an IOC container such as spring to layer controllers, such as the service layer and the DAO layer

TP5 documentation Recommendations on the model

http://www.kancloud.cn/manual/thinkphp5/122950

See how you structure your own program, can be placed in the model layer, then in the design of the method to consider the good extensibility and reusability. At the controller level, the data operations of the model layer operate as much as possible at the atomic level.
Now you prefer to add a service layer, then you can make the controller and model layer look more beautiful

The standard MVC is like this.
The model is responsible for database reading and writing as well as various business logic.
Control is responsible for receiving parameters, filtering parameters, instantiating the model, invoking the method, rendering the template output, or Ajax, or performing jumps and so on.
But once the project is in progress. Directly in the controller bar, slowly moving the code later. Integration

Where you have to look at the designer how to think about it ~ if it is a mess on the abstraction of a layer of it ~

