MVC no wonder, many programmers can understand the concept of MVC seems wrong, in other words they have been wrong with the MVC, although even then the software can also be written, however, the internal organization of the software code is unscientific, this will affect software maintainability, portability, reusability of code.
That MVC Model, View, Controller Model i.e., the view controller. I find that when discussing technical and colleagues, read other people's code, many programmers tend to put business logic Controller software, the code database access operations on the Model inside.
The final software (website) code structure is, View layer is the interface, Controller layer of business logic, Model layer is database access.
Do not know if you know another three-tier architecture model of software development, and it MVC similarities are also divided into three, namely, the UI layer represents the user interface, BLL represent business logic layer, DAL layer representation data access. Three-tier architecture was a smash hit, popular MVC after it disappeared, but now it seems, it seems to be just a face-lift, dressed as MVC way, and by the programmers are welcome, because it's such a hierarchical manner and MVC previously described exactly the same.
Besides the straightforward point, many programmers as the MVC in three-tier architecture with, this seems no problem, after all, is also a three-tier architecture and MVC architectural pattern par. The problem is with the idea of three percent write MVC architecture, then write something neither three percent is not MVC architecture, to be nothing like a grotesque. Familiar Dragon students should know this episode, the Tibetan Fanseng Jiu Mozhi forced to use a small non-phase power Taoist-based practice Shaolin Yi Jin Jing seventy skills and ultimately lead to obsessions. In fact, using this example to describe the current thinking by some programmers to write the three-tier MVC most fitting, three-tier architecture is the core idea for the decoupling between the layers and interface programming and interchangeability, no MVC framework this concept, because the problem MVC to face this problem is not just three percent of architecture to face, so to write MVC-based architecture of three percent is not going to have the core essence of the three-tier structure, in other words, this code give up the essence of MVC and three-tier architecture, access to their dross, it is foolish encoding.
I Tucao so much, Tucao If for reasons not tell you what is estimated to be sprayed dead person, the following is said on the nature of MVC principles and proper use, of course, here refers to the MVC MVC purest, for various types of software, not merely a variant of MVC Web framework, however, remain the same, the text of the MVC idea also applies to Web development.
To achieve the goal of MVC is the software user interface and business logic to make the code scalability, reusability, maintainability, flexibility strengthened.
View interface layer, a business logic layer Model, the Controller View layer and the layer used to schedule Model layer, the tissue reasonable user interface and business logic together since the binder effect. So the contents of the Controller can be as little less, so as to provide maximum flexibility.
For example, there is a View submit data to be processed in order to achieve specific behavioral Model, View usually do not submit data directly to the Model, it will first submit data to the Controller, and then forwards the data to the Controller Model. At this time, if there is a change in the business logic processing mode, it only needs to replace the Controller will be in the original Model Model can be a new implementation, the role of the controller is simple, for different and various Model View organizations together, the way to pass the message on behalf of the two sides, and nothing more.
Rational use MVC There are many benefits to a full eleven extremely difficult task. Here we demonstrate by example to a negative side of the benefits and proper use of MVC basis.
As previously stated, many programmers prefer to put business logic Controller, I strongly oppose this approach, I will now prove the error of this approach.
We know that when writing program, reusable business logic is often the scene to face. If the business logic written in the controller, to reuse it's the only way is to lift it into the parent class, through inheritance to achieve code reuse. But doing so would bring a huge side effects, contrary to an important design object-oriented principles: interface isolation.
What is the interface isolation, I am here to simply talk about. Plainly speaking, the interface isolation is required when a class inherits from another class, if there is less than the inherited class method or property is inherited classes, inheritance is not going to achieve this. If you really have to inherit a last resort, we also need to mention removed from the inherited class that contains only some of the features of the new types of needs, and ultimately to inherit this new type is the right approach. In other words, when implementation inheritance, not to inherit those things in reach.
Back to the topic before, when inherited from the parent by way controller reuse business logic, often in order to reuse a method inherited a lot less than the method appears, on the surface it seems to be no problem, but it will the code becomes difficult to understand,
in the long run, the software code will be developing unhealthy.
You know, use inherited condition is very harsh, we learn an object-oriented inheritance feature programming change, the first lesson is that only meet the IS-A (a) if the relationship can use inheritance, if only reuse code, and we use reason not inherited. Use a combination of code reuse is a way to promote, that is, the relationship between the so-called HAS-A (a), I believe that every programmer heard of "less inheritance, there is a combination of" this sentence, this sentence is software development industry pioneers tempered summed up, it is worth us to follow.
We can call each other between the Model, the Controller can invoke accessible Model, so the business logic in the Model can be flexibly used in combination code reuse.
The Controller is not invoked between each other, to reuse code can only be upgraded to the parent class code, through inheritance, it is clear this approach is neither correct nor flexible, and therefore do not advocate completely.
In summary, just code reuse hell with this, it is enough to "thick Controller, thin Model" This idea MVC unhealthy.
Now that we know about how the code should be distributed between the three MVC, know these, and also know why. Next we from another point of profound analysis MVC, the cleaners it off, let it show naked in front of us.
As we all know, GoF summarizes over 23 design patterns, this 23 was designed to be the cure for certain programming problem, which is the industry recognized.
MVC is a model, but in addition to GoF summed up this 23 design patterns, it is not exactly a design pattern, it is a combination of a variety of design patterns, not just a single one mode.
MVC composed of three modes are combined mode, tactics mode, observer mode, MVC play in the software development power, is ultimately the three modes of tacit understanding. Those who seek to design mode useless programmer, learn as long as you use MVC, design patterns can not be separated.
Note that the following three knowledge-based design patterns, if not the concept of these three design patterns, might be difficult to read.
Let me talk about what kind of role-playing in MVC pattern combinations.
Combination active layer pattern only in the view, the view layer is implemented with a combination of patterns, of course, here refers to the realization of the underlying implementation is done by programming framework vendors things, do not need programmers of ordinary intervene.
Class hierarchy combined mode is a tree, and when we do Web page view layer is html, html structure of the tree is not exactly right, which is actually a combination of modes of application, only browser vendors have been related to the interface help us to do work out, but it is indeed part of our MVC application, but we do not feel nothing, which is why we feel that View is reason to implement the simplest and most unambiguous layer.
Other user interface program other than the web, such as WPF, Android, http: //ASP.NET and so are using a tree structure to organize the interface control object, because the combination pattern is a common solution interface design from the total extracted of. So much MVC combined mode is selected, as it combined mode is bound to exist in MVC, because it comes to user interface, combined mode shall deposit. In fact, if not understood combined mode, the programmer does not affect the right to use the MVC, there is a combination mode of the present position in the reach of the programmer.
However, the observer pattern and strategy pattern becomes more important, it is the real part of the MVC in contact.
Mode observer composed of two parts, the observed object and the observer, the observer also called listener. In correspondence to the MVC, Model is the observed object, View observer, Model layer once changed, View layer i.e. update notification. View layer and the Model layer between each other is held by reference. Web MVC in the development of our program, because the spacing of the business logic of html and Model layers of a layer view http, so the association can not be displayed, but the relationship between the viewer and listener they did not change. When View submit data to the server via http, Model receives data on the server to perform certain actions, then by the result http response back to the View, View (browser) receives the data update interface, is it not receive a notification and execution behavior update it, is another manifestation of the observer pattern.
However, from the Web, when to express a purely MVC structure by the time the code between View and Model undoubtedly the observer and the observed relationship, based on observer mode based on the theory. Even on the Web because of http barriers to achieve real results in a little aliasing, but the core principles and ideas of philosophy is the same.
Finally, the strategy pattern. Strategy mode is the relationship between View and Controller, Controller is a policy View, and Controller for View is replaceable, the relationship between View and Controller are many, the actual development scenarios, often encounter a View Controller by multiple references, making it even slightly a reflection mode, but it is not so intuitive.
In summary, the relationship between the layers corresponding to the MVC design pattern
View layer, to achieve a combined mode alone
Model View layer and a layer, to achieve the observer pattern
Controller View layer and the layer model to achieve the tactics
MVC design pattern is these three together with, and understand these three design patterns, MVC will be no mystery at all. If you do not understand these three design patterns to learn MVC, that no matter how science is always a little knowledge, with the time inevitably will not want a problem.
Back to the top of the business logic once again discussed the issue should be placed on the Controller or the Model, from the perspective of design patterns, strategies mode strategies are usually small and thin, does not contain too much content, Controller is a policy naturally should not be placed on the inside too much content, or to replace a new one will be very troublesome, at the same time also destroy the View-model of the observer pattern, strategy pattern if that is achieved between the View-Controller has achieved observer mode, this confusion is the root of evil, it is to create a tar pit into which the programmer can not extricate themselves culprit. It should not, should be avoided.