Big talk fat model and thin Model

Today, when the business is completed to a certain extent, I checked the code and suddenly found that the current code is a bit strange. It is strange that there are many files in my model. Each file corresponds to a table in the database, and there is almost no logic code in each model. For example:

What is the reason? Because the rdb_model class implements Orm, I inherit this class to use the operations of ORM.

 

But this really makes me very uncomfortable. Why should I write a class that has nothing to worry about? The question is whether the fat model is good or the thin model is good?

 

It is hard to imagine that the code in my project is fat controller and thin model. That is, my model completes the ORM encapsulation process to make it easier to use in the controller. To be honest, writing down the functions in controller is very comfortable. But is it against the dry principle? If it is thin enough to encapsulate only the ORM model, you can close your eyes and say that there must be a lot of redundant code in the controller. This is indeed a bad practice. The redundant and shareable codes in the controller are not abstracted, which of course will cause code troubles in the future.

 

Let's take a step back. What if the model is no longer so thin? We put all the basic methods into the model, but we still stick to the method of a table and a model. Then the following method will be put into the model:

The problem is that comment_model is bound to be used here. This model is the comming of the comment table, but it is not implemented in any function.

 

If you would say this is actually no problem, then the following problem arises: Now the access traffic is up, we will not retrieve the data from the DB, We will retrieve the data from the DB and store the data in the cache, then, you can fetch data from the cache next time. At this time, the question arises: is the cache added to the Controller or the model?

 

This point of view has different opinions. From the perspective of the domain-driven model, cache does not belong to the domain model category. It has nothing to do with the domain data logic and belongs to the application layer category. But from the MVC point of view, the model layer is the abstraction of data acquisition. The controller layer only manages data re-organization and connection, and where data comes from is not in the scope of Controller Management. Therefore, the data is from the database or from the cache, which should be managed by the model layer.

 

What if I try again? All data logic is written in the model? The following strange code will appear:

There is only one row in a method !! If you do this for addition, deletion, modification, and query, it will be redundant. It is always unpleasant to have so many codes that you don't need to write. The call is a single sentence. Why do we need to encapsulate a layer?

I think all the differences should be clarified first what is the abstraction of the MVC model? If the model is the abstraction of the data structure, the ORM has completed this abstract behavior, and a database and a model are implemented as follows. But I don't think so. Model should be an abstraction of business logic. That is to say, the model layer should touch on the specific business logic, which encapsulates the business logic into a language that can be called and used by the Controller. This is very consistent with the domain-driven design. The model layer encapsulates the business domain into a model layer. It is a kind of "Translation" work, which translates the real business into a programming language. This model encapsulation makes sense.

Then return to the Controller or model perspective of the cache. In my opinion, the logic for retrieving data from the cache or from the database in the business field should be placed in the model, because it is also a "Translation" process. If this logic is implemented by the application layer, it needs to be concerned about whether the access and the access are both cached, and whether the returned data is consistent. The logic of this layer and the actual "running environment" is put on the application layer that should have been clearly defined.

 

But what? According to the old man, different situations are analyzed.

Is the same logic for foreground and background? The foreground here refers to API, web, WAP, and other methods. The background refers to operations, review, and other background. My point is that the front-end should "Fat model" as much as possible or forcibly. This means that all accesses that can be scattered in the model are placed in the model. This is the default point.

 

This method is reasonable at the front-end. If you add a cache on the table cars, you only need to modify the three methods in the model and do not need to modify the business application logic !! In this way, the model implementation in a specific environment is completely abstracted.

But what about the background? The background is actually a forcible intervention to the actual data. Therefore, we seldom touch the cache and other optimization mechanisms in the background. In addition, the background development does not need to meet the needs of high concurrency, And the development time is usually too short for the foreground. Therefore, the "Fat controller, thin model" model developed in the background is very suitable. I don't even think it's too much to use "Fat controller, no model.

 

Therefore, raise the flag of the specific analysis of specific problems, and this problem is a conclusion.