If you use MVC pattern in your project, what kind of architecture do you have? How is it divided?

Advantages and disadvantages of MVC pattern

Let's talk about advantages first:

1) separating M.V.C allows different experts to be responsible for different modules. Generally speaking, part M is the responsibility of experts who are familiar with database and network transmission; V is for experts who have research on UI. How tempting it is for project managers, division of labor means that efficiency can be improved, and the software development process can be handled according to the traditional division of responsibilities. For developers, they can also focus on one area. The premise of this is that the interface should be clear, and the separation thought of MVC is providing the foundation for it.

2) Once the part of V changes, it can be reconstructed quickly without causing rework of the whole project. Now some changes in the software presentation layer are really too fast …

3) Part M, because it is abstract enough, can be easily reused, which conforms to the idea of OO. On the other hand, we can use JUnit and other unit testing tools to test M to ensure the engineering quality.

After talking about the advantages, let's look at the disadvantages:

1) Using MVC pattern (including other modern patterns) implies that we can improve the readability and robustness of the program by generating more classes. The incidental disadvantage is the expansion of the number of classes. Tell a joke, MVC is the most convenient code extender, just like the quick-acting powder used in dough making. I believe everyone has a deep understanding:)

2) Although 2)MVC defines the meaning of each component of M.V.C, it is not specific and there is no clear connection between them. So there are many arguments in other aspects besides View, and everyone wants to take their own understanding as a positive solution. In particular, "whether the model is a collection of screen data or entity data" and "the role of the controller" are two frequently debated issues. As mentioned earlier, there are many kinds of MVC, which also leaves many traps for beginners. Several common practices will be analyzed with examples.

3) 3) The cost of MVC is high. But please note that this is relative. Generally speaking, the bigger the project, the more you can see its advantages.

Practice of general MVC pattern

The following will introduce several common practices on the midp platform, and finally the practices I am used to.

M-v form (or MC-v, m-VC)

This is also a common method in j2me. In a word, this method takes the screen as the organizational unit, so it is very suitable for the development of RAD tools. A screen and its controls are abstracted into a VC class, in which there is a private model object to represent the data elements to be used on the screen. Screen objects do not store any entity data, which are organized in model objects. Probably because the screen object is intuitive and the function of the controller is not clear (most of its functions are replaced by views or models, depending on your implementation), it is often called model-view mode. Its form is as follows:

Class MyFrame extension framework {

Private model model;

Private StringItem name;

My Framework (Model Model) {

this.model = model

name = new StringItem(model . getname())； //Request data for the model

Add (name);

}

}

Class model {

Private string name="M-C mode ";

Public String getName(){// This is a service interface.

Returns the name;

}

}

What we have seen above is a typical M-V model, and we can understand the significance of this screen-centered separation. Model organizes the data on the screen, and view asks Model for the data it wants to display. Note that this operation must be accessed through a pre-negotiated interface and cannot be directly operated. If there is a complex transaction logic (an operation selected by the user), some people put it on the model side and some people put it on the view side, but it is usually placed on the model side, and then the model has a serious controller color.

The advantage of this form is that it is very intuitive, and it also separates the display from the data in a limited way. If you often read j2medev.com webmaster Mingjava's articles, you can see that most of the examples he wrote are this model. This pattern is often used in RAD tools.

The disadvantage of this model is that it encourages you to think from the screen like RAD tools, which often leads you to fall into the trap of RAD-not considering the flow of the transaction first, but directly analyzing the problem from the user interface, which often kills your whole idea.