In the MVC model, the controller is a pipeline and the Model is the processor. But many times the Controller will need different contents from different tables. In this way, there will be many functions in the Model such as get_name, get_info, get_id, etc. that can be completed with just one Query. It feels cumbersome. In fact, it would be good to write a Query where the Controller is to be used, but this breaks the rules of MVC.
The current idea is to put the most used functions in the Model and leave the scattered ones in the Controller.
Please give me some opinions~
Thin C, fat M, C should not exceed 15 lines
In fact, the problem you mentioned can be solved by many frameworks, that is, the active record function, which dynamically generates query statements based on the code. It was first promoted in the rails framework and gradually implemented in other languages. For example
In fact, if your framework supports active record, we don’t need to write a line of code in the model for such a simple query based on the primary key. The model base class is assembled into a suitable query statement based on the method name you call, and Return query results to you.
I don’t know what language you are using, but basically all scripting languages currently have active record implementations. You can implement this function in your own project, which will also bring benefits to subsequent development.
Problems that can be constrained in the code are more effective than stipulating some design principles, because you cannot guarantee that every developer has the same level.
You can refer to Fowler’s pattern book, transaction script, table module, and domain model three styles.
I don’t know how CI implements active record, but the small function you mentioned is a magic method used in many PHP active record implementations, or the code generator automatically generates it for you, so you don’t need to write it yourself.
For example, active record is implemented in doctrine like this: If there is a table foo with fields bar1, bar2, and bar3, doctrine will directly generate four files according to the table schema: FooTable.class.php, FooTableBase.class.php , Foo.class.php, FooBase.class.php. In the two base files, there will be a series of automatically generated getters and setters such as getBar1(), setBar1($param). The base file is not allowed to be modified by programmers themselves, it will change as the schema changes. The non-base class directly inherits the base class, so it looks much cleaner
Put your application logic in the model
Let’s do layering. The controller is responsible for page-level control logic
。。。。。。。。。。。