Also on PageController/FrontController and MVC

Misunderstanding and misuse of the term MVC in the industry, especially the confusion with PageController and MVC. under ASP. NET, it is typical to make sentences from the following two articles:

Http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesPageController.mspx? Mfr = true
Http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesFrontController.mspx? Mfr = true

From the perspective of the two articles, there may be sometimes incorrect conclusions. It seems that PageController is MVC. in fact, there was an early article on MSDN about how to port MVC from other systems. NET, where the header is more reliable. in fact, the clever Microsoft author has not mentioned in the two articles that PageController or FrontController is MVC. for example:

"Front Controller. The Front Controller defines the same Controller for all page requests, so it can make cross-page navigation decisions. "

This statement is irrelevant to FrontController and MVC features.
FrontController is only implemented by the Controller. In many cases, FrontController is applied instead of MVC. Therefore, besides controller, FrontController does not have other features of MVC. in addition, the FrontController mentioned in this article is used to coordinate all requests sent to Web applications. This solution describes the use of a single Controller, which is not consistent with the role of the Controller in the MVC structure. the Front Controller and MVC are listed separately for Glossary, and the problems they are targeting have been differentiated. However, at the beginning of the article, they are intentionally misleading:

"You have decided to useModel-View-Controller(MVC)Mode separates the user interface logic of a dynamic Web application from the business logic. You have investigatedPage ControllerMode, but your page controller class has complex logic and is part of a deeper hierarchy, or, your application dynamically determines the page navigation based on configurable rules. "

To be honest, this is a mess. The Front Controller can solve a series of problems such as page navigation and identity authentication. It is characterized by centralized general work. What is the relationship between this and MVC? Do Front Controller models require attention? I have implemented the Model and View together. It is definitely not MVC. Then I use the Front Controller to navigate. Isn't it the Front Controller? Or do I say that my implementation is a variant? Just like the following sentence?

"Model-View-Controller. Page Controller is an implementation variant of the MVC Controller. "

This sentence uses the so-called "variant" to draw the relationship between PageController and MVC. in essence, PageController is not MVC, because its perspective is completely different from the target. if we examine each PageController separately, it can be said that it is a distributed FrontController. especially for Microsoft, aspx is aspx as view. cs subclass, while Page is the implementation of HttpHandler, and Model in this mode can not be mentioned at all. this means that the View and Controller are actually an object, and how the Model is implemented, and how the Model/View/Controller interacts are unrelated to the characteristics of the structure of PageController. the PageController mode does not focus on MVC's concerns. It is neither MVC nor a subpattern of MVC.

Of course, if the interaction between your Model and PageController is properly implemented, it will become a Document-View-like mode. Microsoft also calls this mode the "variant" of MVC ", it is used to attract beginners to promote the notorious MFC among model fans. these arguments are purely mixed-water practices, and you must be cautious about them. Although MFC and ASPX are useful in some aspects, the implementation method of them is called MVC and does not harm your own interests, however, if these terms confuse the definition of nouns, they may cause obstacles when you read pure technical articles. When writing an article, these ambiguous concepts will bring potential harm to beginners.

As MVC has been widely used and abused on a large scale for more than 20 years, it seems to represent a good design, so basically everything should be checked against MVC. for example, the above two articles are basically text games. They can be said to be articles by followers of Microsoft's flickering mode. the general situation is that, as long as a clear Controller can be identified, many people may choose MVC or a "variant" of MVC ", regardless of whether the implementation of Model and View and the specific implementation method are indispensable for the implementation of this structure, MVC emphasizes the relationship between Model, View, and Controller, therefore, I personally think that it is not possible to equate "the structure that can be converted into MVC" with "MVC structure": the wider the scope of a noun definition, the less reliable it refers.

In fact, Fowler makes it clear in an article that the method widely used on the Web is called InputController. I also agree with this. For example, some MVC implementation methods on RoR and php should be strictly investigated according to the classic MVC structure, you can also say that it is not completely Complete MVC, but those methods are indeed close to the fact that MVC has almost all the basic features of MVC. Therefore, MVC is more convenient than PageController and FrontController. complete MVC-> incomplete MVC. If it is incomplete, it cannot be called MVC.

In fact, it is not MVC. It does not mean that such a structure is not unreasonable. Each model has its own scope, and the applicability of different models often overlap; it is precisely this kind of practice that we have to climb with MVC. Instead, it makes PageController and other models a little shorter without knowing it. in POEAA of Fowler, FrontController/PageController and MVC are three different models. The above two MSDN articles also provide a reference for POEAA at the end, it is impossible to know this broad-based division method. To tell the truth, such an article should be put aside from the articles written by confused people.

In addition, FrontController and (PageController or MVC) are not mutually exclusive. apart from the similarity brought by PageController, a special form of distributed FrontController, in fact, FrontController can coexist with PageController or MVC as a peripheral controller, process common requirements. for example, if we discuss WebForm and ms mvc two days ago, we can implement a FrontController. Then, WebForm is more appropriate to use WebForm (PageController), while MVC is more appropriate to use MVC, frontController provides external unification and navigation, and handles common tasks such as verification.

I personally feel that many people now have some good developers' misunderstandings about the MVC, MVP, MVPC, and other pattern structures, which are determined by the absence of uniform descriptions, this is also true for Fowler's separation of the script/table module/domain model. Recently, I have been working on some articles that can better describe these schema patterns to see if these questions can be clearly explained once, A common language is provided. at the same time, this method can also clearly differentiate ActiveRecord, er, and other topics, and provide a preliminary guidance based on the recent popular Web applications to determine the following problems:

1. When to use music videos (P/C/PC) or other more complex/simple modes.
2. When to use the table module, table entry, and domain model.
3. When and how to use table modules and other data-driven and Domain Models in a more object-oriented manner, why are they uniform, not what Martin says.
4. Other topics around these topics.
5. Give you the irrationality of your practice and tell you when to change and how to change it.
6. Give you the rationality of your practice. You no longer need to worry about "my approach is not Object-Oriented"/"my approach is not MVC" and other advanced issues.

Many people think that my article is too long. I promise that my content is much shorter, more refined, and clearer than Martin's Enterprise Architecture Application Model. as the "creator" defined by me, I do not mean that I have a deeper understanding of these aspects than Martin, but as a child who picks up shells by the sea, I feel that I have found a more beautiful shell. I can tell the story more clearly in some aspects of the problem. of course, if you think that a Chinese person, an ordinary developer, or a netizen around you cannot pick up such shells, you still have to read commercial articles that are more secure, so I have nothing to say, I just want to share it with you and show it off without your face ~

At the same time, I am using this description for practical guidance recently. It also takes some time to verify and correct it. If you are interested, please wait. in order to verify the feasibility of this description method, Martin can also refer to and improve it. I personally plan to write a more rigorous style and translate it into English, however, my English writing skills are poor. I wonder if anyone is willing to cooperate? In addition, these contents can be extended into books, but I have no experience in publishing books and have no time to become a qualified technical propagandist. In this regard, if anyone wants to work on behalf of me, they can also cooperate.