What code should be included in the YII2 model?

In addition to the model contains data validation and basic deletion, but also what code to write? If you want to add, delete, update, data preprocessing needs to be based on a variety of criteria to judge, but also to do multiple table operations (there is no one-to-many, many to a relationship), there is a large part of the code, write to the controller feel very big, write in the model feel sometimes not, Are these all written in helper, or are there other good places to organize?

Reply content:

In addition to the model contains data validation and basic deletion, but also what code to write? If you want to add, delete, update, data preprocessing needs to be based on a variety of criteria to judge, but also to do multiple table operations (there is no one-to-many, many to a relationship), there is a large part of the code, write to the controller feel very big, write in the model feel sometimes not, Are these all written in helper, or are there other good places to organize?

With feeling and experience, my answer is purely throwing bricks.
There's no particular model concept in YII2, including documents and examples, and I feel like they just want everything to be done with ActiveRecord objects (even if the form is inherited), but it's really a bad thing, Because when the multi-table linkage, the object boundary will become very blurred. However, in fact, I am in a project to customize the model layer after the other side unexpectedly still use this style is not YII2 recommended for the project, so I protested the end of the paragraph, so I spit on the trough unceasingly.
In my opinion, the ActiveRecord object is a mapping of the data table, it should only deal with internal things, which is undoubtedly a lot clearer. It is the entity map of the data table, not the model.
However, a lot of times between multiple tables must be linkage, such as the creation of orders when the need to operate the order details, then this logic control should be completed in the model.
In addition, if the controller and ActiveRecord are done by different developers, the model layer is also important and can be used for both sides of the coupling because allowing direct calls to ActiveRecord in the controller is actually quite risky.

As for the model you think is not enough, you can choose Service, Plugin, filter, etc., and not just helper.

Add: Seems to have been not relative it, haha
I think model is a more complex data model based on the data table, often indicates the developer's understanding and definition of the object, for example, we have order form and order Detail table, but this is not the object level of data, and Ordermodel is the declaration of the Order object, an order not only has the order information, It also includes order details and may even be linked to logistics, invoices, etc.
I usually include in the model
Constant definition, if you need to set some specific markings
Things to deal with If you need multiple ActiveRecord linkage
Simple crud, if you need to isolate ActiveRecord, that is, the contract controller does not go directly to call this type of object, but must pass the method encapsulated in model
Other, I think the helper is mainly for the front-end use, so a method commonly used but the front-end, then can be placed in the model; In addition, some methods may not be able to confirm their attribution, that is, Amodel need, Bmodel also need, also simple, both declared, but one is the specific logic, The other is just a quote.

You can use the behavior (behaviors).
Put the ambiguous common code in the behavior.
Similar to traits.

or components. Components

The data properties and behavior of the object.

