The interface layer is separated from the business logic.Program. But in fact, in many projects, the interface layer has been grabbing the business logic layer (at least two of my experiences, some time ago, the project had to provide the Excel import function, which is equivalent to adding another platform, the business logic layer only acts as the data access layer under the call.
For example, when you add an employee information, the page will judge whether each field meets the specific conditions, and then access the database to determine whether the employee information has been added. If not, add the data and then determine whether the data is successfully added. At this point, the interface carries too many business logic. If we need to add the function of importing employee information, we need to addCodeWrite it again.
In general, many people have done some things that are supposed to belong to the business logic layer on the interface layer. If it is just a platform and the business logic is not shared, it is understandable. However, if the project is a little larger, the responsibility cannot be clearly divided, and there are too many repeated logics, it will be a disaster in the future maintenance. We can put the field judgment logic in the partial classification of the modle (because some validation of the field is simple, common, and diverse, if it is directly in the business, will affect the readability of the business logic), other logic is still in the logic layer where it should be.