Interpretation of the MVC Framework in as3

I really don't want to discuss this issue. MVC and TDD are the concepts that have been hyped up. In fact, they are already special and cannot be verified by common methods. Experts say that it may not be good because it is an expert. Some people say that it may not be good because it may have been brainwashed. Originally, as long as it was a thing, there must be support for schools and the opposition. However, in a hyping atmosphere, the opposition voice cannot be heard. In this case, you can only trust yourself. The following is my personal opinion. If you agree or disagree, just listen to me. What is MVC? I don't know when this problem will become a proposition similar to that in the eyes of 10 thousand million people. It may be because there are too many bits and there is no result. The final compromise is like this. MVC is just a word. It can cover all kinds of meanings. Now, who knows what it originally meant? Literally, MVC is a model View Controller (Model View Controller) Model-View-controller. It is a design mode (also known as the architecture mode ), however, this is clearly not the only significance for most people. The concepts of various MVC frameworks, such as message communication, dependency injection, and isolated compilation, are now added to the MVC concept, and because of the overlap and similarity of applications, it is often confused with the concept of a three-tier architecture. The meaning of a term is determined by people's understanding. Since so many people think that messages must be published and instances must be obtained through reflection, and model modifications must be updated to try to calculate MVC, MVC is such a thing. However, this is almost impossible to discuss. So here I will look back to the original truth, starting with the most basic concepts, or a little bit of name. For a program used for display, only view is started ). We need to obtain and display the data, that is, the write code calls the interface to obtain the data, and then update the view based on the data. The data here is only a temporary variable or exists in a view attribute. Obviously, in this case, the data depends on the view. If the view does not pass or does not exist, other modules will not be able to access the returned data, it needs to be called again, which is obviously a waste and inconvenient. Therefore, we store the data elsewhere and share the same lifecycle with the view. Therefore, the isolated data is defined as a model) (I must interrupt the description here, the model! = Data, just in this simplified example, the model = data. A model is a separate module that provides content for a view. Specifically, there are various internal situations. Providing data is only one of its functions.) at this point, is the most basic principle of separation of the presentation layer. However, there is something that is inseparable-the code that originally controlled the loading of data. It is responsible for obtaining data and instructs the view to update data based on the data, and its direction has two options: do not add to the view (this is the common practice ), if the model needs to correspond to multiple views, it is impossible for the model to disappear out of thin air because of separation. Then we put forward this part of code as a separate part, that is, once the controller is isolated from the Controller, the specific code connecting the model and view is no longer above the two (of course, the calling code is still there), but an independent part. It has its own name and won't be mixed with other irrelevant content. It is very clear and easy to locate. Models and views focus only on controllers, but not on the other. Their code is to handle their own affairs, and all other things are handed over to the Controller, which makes their own functions very independent and reduces the elements to be considered. This is only the movement of the code location, but after this movement, the most vulnerable content will be changed, but the Code with the least amount of code will be put into the Controller separately and managed properly. Similar to the switch that will be scattered across the room in one place, the switch is arranged neatly and the name is marked, making it a remote control in the hand to play, from then on can travel to all the location of the room, find the things hidden in the corner and release them in daily activities. Its meaning is self-evident. This is enough for MVC. What can be done once the MVC Framework separates views, models, and controllers? Because views and models only process their own affairs, and calls to controllers are just a piece of code, they can be isolated. The person in charge of this part of the Code only needs to care about his own affairs, not the whole environment. Similarly, controllers only need to know the external interfaces of views and models, rather than the specific implementations of the controllers, that is, they only need to care about the environment. This separates the knowledge required by different developers. Each developer only needs to know a limited amount of knowledge, but can be merged smoothly. This is the basis for the division of labor. After that, there is only a simple call code for the relationship between the three. In order to completely separate and decouple the call code, you can change the call code to send messages or other dynamic forms, so that you can compile independently when there are no other parts. Different people can complete their own parts independently in different work environments and simply merge them at the end of the release. This is indeed the most ideal collaboration mode. To achieve this, a message framework is required, and this is the main task of the MVC framework. In addition, different frameworks are added to other design modes to provide various additional functions. Automatic dependency injection is one of them. Other middleware may also be added to further split the layers, such as separating the logical part of the view, so that the drawing and location code will not be mixed with the logic Code to facilitate division of labor and modification. Using the observer mode, the changes to the data part can be automatically synchronized to the view ...... The MVC Framework refers to "Implementing the MVC Framework", rather than "only implementing the MVC Framework". It only implements MVC, and the functions of this framework are too poor, after all, MVC is something of that degree. In the end, after these steps are completed, they become what the average person sees on the surface. Although there are various types, we call them "MVC frameworks ". The only function that can be implemented is the naming method. MVC is not a three-tier architecture. Here, we must provide a supplementary explanation. If we do not clarify the relationship between MVC and the three-tier architecture, there will be a lot of misunderstandings in the future. These two things only sound like the names of various parts. MVC is a view-controller-model, and the three-tier architecture is performance-business-data access, without any similarities. Actually, they are two completely different things. However, because MVC Architecture is often used to implement a three-tier architecture, many people think that the former already contains the latter. In fact, this is not the case at all. We can think that the logic layer and data layer of the three-tier architecture represent the model in MVC, or that the MVC Architecture is the presentation layer of the three-tier architecture. In fact, MVC has always been called the presentation layer architecture. Therefore, do not separate the presentation layer from the business layer, so it is easy to replace the server language. databases and other such things are put on the MVC header, although it sounds like "view and model separation, it is easy to replace the service interface. In fact, there is no relationship at all. Many flasher think that the server has already used a framework. It is also based on this misunderstanding that the flash part does not need to implement MVC itself once inside as a view. The Flash part is in the presentation layer of the three-tier architecture, rather than the view in MVC. Since flash is used to replace the original html/JS part, the content of the original MVC part of the server cannot be implemented (replaced), leaving only the business and data access layer. Therefore, this is completely not the same. MVC is an architecture of the presentation layer. The task of the presentation layer is to present data, and all interactions are to present data. Although it is not only capable of presenting data, it is indeed born. The advantages and disadvantages of the MVC Framework are also mentioned above. Basically, the L structure is clear, and the L controller can be easily inserted into all parts of the L architecture and can be transplanted independently, replacement of the L module has clear responsibilities, which facilitates Engineering Management l it is easy to conduct unit tests and then the disadvantages are described as follows: L is more complex, it is difficult to implement more class L, and more code, workload increases. l a little slow. l it is not conducive to overall debugging. l generally, I cannot get the help of IDE. I have some ideas about the communication framework. But I'm sorry, this is a negative comment. After all, the positive opinion of MVC has been mentioned to a certain extent, and I do not want to repeat it again. This opinion also refers to the communication framework, the most important part of MVC at present. The current MVC framework has a common feature that will be decoupled through message communication, so that the three parts can be separated. This seems ideal, but decoupling itself is costly. Currently, message decoupling is completed by adding a third party, and now this third party is the string that marks them. In addition, different frameworks have different intermediaries. The more intermediate links, the higher the chance of errors, these intermediaries do not produce errors during compilation (or even runtime. In addition, the lack of IDE assistance makes it difficult for you to read other people's code, including writing your own code. Due to the complicated call relationship, switching multiple jumps in each module may waste time. At the time of modification, the other party has no knowledge because there will be no errors or the relationship between modules may be damaged. Therefore, a more comprehensive system is needed to make up for this defect, such as more detailed documents, stricter version control, and more standard development processes. Even it is better to strictly execute unit tests, because even a simple spelling mistake at the time of modification will lead to unknown problems. In short, developers need more energy and development costs. Compared with them, it is trivial to write more code. Therefore, the MVC Framework may not always improve development efficiency. Its main function is to make your development process organized and clear, so that many people can perform parallel operations better during development, so as to avoid greatly reducing efficiency. However, if you don't need it, it can be organized and clarified, and parallel development can be simply completed using SVN/git. The benefits of using it are very limited, and the cost increase cannot be ignored. Therefore, it is said that the MVC framework is not suitable for small projects or even some medium-sized projects, because they can still do well even without relying on these features of the MVC framework. In the same way, they can separate modules to Develop interfaces, even if part of the Division of Labor overlaps, SVN can be used for proper management due to a small number of users. In addition, there is a very important point: there is a distance between ideal and reality. If your developers are very good, you can use the MVC Framework correctly. under appropriate circumstances, you can indeed take advantage of it. But what if not? The MVC framework generally only provides functions, but does not limit your use of functions. You can also write the logic required by the Model in the view, place the logic that should have been put in the command in other places, and implement various odd statements, and then apply the framework mechanically, in this way, we must not only bear the inconvenience caused by the framework, but also have no benefits at all. Therefore, personnel must be trained and those who are useless for training should be screened, which is a huge cost. Even worse, teams using the MVC framework may not be aware of this. They may not have documents, version control, development processes, or even MVC training personnel. The training content is completely wrong. The MVC framework is designed for large-scale projects. For large projects, personnel, systems, management, and processes, these are not problems. The problems are the chaos caused by the large scale of projects. The shortcomings mentioned above are no longer shortcomings. Small and Medium Projects. However, if the MVC Framework does not implement message communication, that is, it does not completely decouple the three parts, it is another thing. The above problems are mainly the problems of the communication framework, not the issue of MVC hierarchy. However, because all MVC frameworks Implement Message Communication, if you want to avoid the above problems, you can only develop the MVC framework by yourself. This is what many game teams are actually working on. Differences between flash and traditional environments MVC was first proposed in 1979. However, there was no concept of a network application. After the birth of the World Wide Web, it took a long time ...... It didn't get popular since its birth, but the reason for the change was simple-because two extremely popular development frameworks include this pattern, which are struts and Ruby on Rails. Then, the imitators flocked. Therefore, in people's eyes, the concept of Struts is actually the first, and then MVC. It is no wonder that the concept of MVC will always be infected with the concept of web, and even be confused with some additional content of the framework. Because struts is very easy to use, let alone anything else, at least it makes HTML look much cleaner. So many people are using struts. This is not necessarily because the MVC mode is required, but because they need struts. Therefore, when the environment changes, we should not use struts but some other frameworks, and whether to use the MVC framework as before has become a problem. Because the environment is different, even if the MVC framework is widely used in other languages, it does not mean that the same should be true in the new environment. The difference between as3 and traditional languages: l as3 is a single language environment, and the problem of Multi-Layer Code mixing is not that serious. L as3 normally compiles all the code at one time, that is, the MVC framework must be compiled together. There is another way to compile a module separately to reduce the Compilation Time, and MVC is not required. L The events and dynamic features of as3 are duplicated with the functions of some frameworks. L as3 currently has a very immature framework and does not provide eye-catching functions. The result is, at least, the MVC Framework of as3 is not so prominent as that of traditional languages. Even if it is used, it will not be as qualitative as struts. In addition, at least in my opinion, the use cost of the as3 framework is not necessarily lower than that of struts. The result is very troublesome when the two are subtracted. In addition, as3 has its own advantages when it does not use the framework. Using the framework will destroy these advantages: L has a relatively usable debugger, when the framework is used, debugging will be troublesome, mainly because of the increasing number of single-step debugging steps. L impede the use of IDE functions. Taking flex Builder as an example, you can jump to the specific implementation of the specified method through Ctrl + Click (F4), and jump to the location where the method is called by searching the reference panel from the implementation of the method. After the framework is used, these functions will become invalid. L flex framework-related functions are difficult to use, such as binding. In addition, flex builder supports the drag-and-drop function of Binding data interfaces to views. It can partially implement zero-code programming, and the framework also hinders this process. In addition, there is another situation in gaming, say corporate applications and websites. The structure of the game is not the same as that used to present data. The user interface in the game may be similar to the previous one, no matter what you think, you cannot apply the MVC Framework. First, you can't say efficiency. For example, a project has three clients working on the development process. One is working on a map, the other is fighting, and the other is working on the UI. The first two have nothing to do with MVC. As a result, only one person is using the MVC framework to develop the interface ...... In addition, before development, development and collaboration are more difficult than the development interface. Since they have done it, why do developers still have to rely on the framework to solve this problem? Of course, some teams with a lot of UI developers do have some meaning. However, in the game development team, the number of such personnel is at least lower than before. If other people discuss interfaces and divide the work according to functional modules, why is the UI unavailable? This makes flash less suitable for using the MVC framework than in general. Whether or not to use the framework should treat programmers rationally as science students, and should use the way science students think (of course, I didn't let you all imitate Sheldon ). In the process of using the MVC framework, whether it is good or bad, you must clearly consider the source of the problem. I think the MVC framework is not easy to use, reducing efficiency. Have you ever had examples of parallel comparison? Are you sure you can improve the efficiency without using it? Is low efficiency possible because it is out of the framework? I think the MVC framework is easy to use and improve efficiency. Are there examples of parallel comparison? How do you know that the credit for using the framework, rather than standardizing the code structure, creating a new collaboration process, or even increasing the developer's level? How does one know that the MVC Framework does not have any anti-effects? I used the framework, saw the results, and then determined the quality of the framework based on the results. This is too arbitrary. As a science student, we absolutely cannot do this. As for those types of connections, they are not supported by people who use a framework because the project is still finished after I use the framework, I am speechless. Without using the existing framework, it is not impossible to implement MVC. As I am talking about, the framework is not easy to use. So we don't need a framework. What should we do? In fact, if you just want to Implement Model-View-controller division, it is just an architecture model. Separate the model and view code, propose the Controller code, and call each other's methods. All references of the model are stored in a fixed position, or in a single example. The reference of the view is stored in static properties or managed in management class. The command can be directly initialized and executed as a function or class, reflection can also be used. This does not require special tool classes to help, and the additional costs are relatively small. Naturally, it can be applied to any scale of projects. Of course, you can also implement a simple communication framework to provide necessary functions, if necessary. MVC is a very good architecture model. It is recommended that you try to use it for any project, but you have to emphasize full decoupling. If you must use an existing framework, be cautious. The simple MVC is the simplest, ignoring the coupled MVC. Recently, we have seen a very simple example. However, this example is helpful for everyone to understand the concept of MVC. This is indeed ...... It's basically MVC, just a little worse. MVC is an architectural model that should be separated at least in terms of structure, even if no file is required, at least let us see who is who (the original text can have no red letter ), therefore, you only need to divide the code into three files, which can be called the simplest MVC. This is the code I added below. The result is that the view only cares about the model and command related to itself, and the command only cares about the view and model related to itself. The model does not care about anyone, which is consistent with the general requirements. Although this is indeed not a decoupling ...... But at least we have achieved the separation of thinking and logic. There are only problems with collaboration. For example, we cannot achieve free parallel development, and this can be solved by adding simple reflection. Therefore, it is not difficult to simply use MVC. There is nothing to give up. In addition, the above is just an extreme example, but even this kind of things has at least 50% of the content compared to not implementing MVC at all. Even using the MVC Framework does not require full decoupling. This is a requirement for scalability, but the higher the requirement, the better. This is a common misunderstanding. For example, many people who use puremvc are entangled in full decoupling, so that with command, the notification must be sent again when the view is changed in command. This type of command is generally written only after the related view and model is complete. For example, how to write a common startupcommand and openwindowcommand without objects? It should be written in order, even if it is not, it can be placed after the view and model. In terms of the collaboration relationship, he can directly access all related classes without decoupling for this reason. Although puremvc virtualizes messages, messages are actually segmented locally and globally. For example, if a proxy changes and all views listening for a message are updated, a notification called I _am_changed should be sent, and different views should listen for and update the message, this should be a global message. However, some messages are partial and one-to-one. For example, if a message called send_data_to_window1 is refreshed literally, the command triggered by it is, the value of the view window1 should be directly coupled to set the value, instead of sending a message similar to refresh_window1, because the name of send_data_to_window1 is determined to be for this view. If it does not operate on this view in the end, is there a problem? Decoupling is decoupled, but the results are not coupled for modules that have a sense of connection, and it is meaningless at any time. Even if the demand changes, the logic changes, so that send_data_to_window1 does not ultimately change window1 data, but window2 data, then the name of the command and related notification must be modified, that is, in the sense of closeness, in practice and coupling is the same thing. Now that this is the case, what is the significance of making it uncoupled and causing troubles for yourself? In addition to the above situation, we also need to consider whether it is really necessary to split the project so carefully. Is there a need to decouple two highly correlated parts for the possibility of less than 1%? For example, a view named shoppanel and a model named shopmodel, under what circumstances will shoppanel not call shopmodel, but something else? In addition, there may be various texts on the panel, so that you can only call store data in your own sense. I really want to call something else. Should I create a new view? And don't forget that puremvc can apply one view to multiple mediators. In this case, we directly coupled the shopmodel In the mediator. What is wrong? Of course, shopmodel is commonly called by multiple views, so we cannot allow shoppanel to be coupled. These rules are actually clear and completely predictable. Even if an error is predicted, it is easily corrected. Decoupling is a means, not a purpose. Blindly seeking "NONE" coupling will only turn your programs into a piece of sand. It is the right amount of coupling that the program can have a definite form and won't become a role. I am not totally opposed to using the MVC framework. This depends on your project type, size, and number of people. Of course, this can be used when conditions are met. Especially in enterprise applications, if you are lucky enough to have six clients, there may be problems without the MVC framework. Puremvc and cairngorm are two frameworks that emerged earlier. Currently, I do not recommend using them any more. The problem with puremvc lies in the lack of practical functions due to excessive emphasis on separation. The convenience provided is difficult to offset its own consumption and the cost effectiveness is low. The problem with cairngorm is that it places too much emphasis on the process of updating the model view, which is too restrictive and inflexible. The subsequent frameworks are much better. Mate uses a global event definition, which is very simple in combination with Flex. Swiz uses control inversion + dependency injection, that is, spring, and the meta-tag injection method is very interesting. If you are interested, you can view the information on your own. Here I want to talk about robotlegs. This is a very similar framework to swiz, but it also has its own characteristics. First, it is based on puremvc, and you can still use it like puremvc. It is an easy alternative for teams that believe in puremvc. He also gave puremvc control inversion and dependency injection, encapsulated most of the functions, greatly reduced the configuration code, and it can be used naturally regardless of the use of the Flex framework. For details about the robotlegs tutorial, refer to: Robot. In fact, I even implemented a dependency injection framework myself, which can be easily added to the current project. The cost is almost zero, but it is still useless. To use one thing, you must check whether it is necessary to use it, instead of using it if it is available. It is not to use it because it has no problems ". It is only possible to use one thing with benefits, especially when there is a loss clearly. It's just silly to determine your behavior with the reason for self-satisfaction such as "looks more formal. Of course, if you need it, you should not hesitate to use it. Don't be influenced by people who complain about the framework. Most of them have their own problems and the reasons may not be correct. You don't necessarily leave them alone-the premise is that you really need it, in addition, all the conditions required to use the framework should be completed. The general misunderstanding is that there are really few people who use the framework, especially those who are at a lower level of Action Script. On the one hand, this has contaminated the reputation of the framework, and is also one of the reasons for not recommending the use of the framework, because the personnel level limit is also an unavoidable real problem in the actual project. If you decide to use the MVC framework, you must increase your understanding. Let me pick up the most common questions. L message communication is not used. Even if MVC message communication is used, it is only a means to use the communication function of the framework to send messages between views, and discard all other functions, it is better to directly use the event, and another MVC Framework will be able to find something. The key of MVC lies in the distribution of code logic. Communication is just a gift. They wanted a gift and threw away the original product. We didn't buy a coaton, right. But if your purpose is to give gifts, there is actually nothing. For example, if you want to use this communication framework to send messages, you do not want to use its MVC, or the MVC part is self-implemented. So I suggest you simply implement the message part by yourself, and others will never be better at yourself. L since the MVC framework is used, it is not easy to figure clearly. Loose coupling is not just a form, but aims to reduce the relationship between modules. Therefore, if you cancel the coupling between the two modules on the one hand, and coupling the content of other modules on your own, your behavior will become meaningless. At present, some people are introducing other classes at will, on the one hand, in a rigid framework, and on the other hand, it is such behavior. Those classes can be introduced, but in this way, the framework itself has no meaning. If you don't need a framework, or you don't want to do this, you can only choose one here. L The mediator knows everything about the view, and the view does not know mediator at all, rather than for colleagues who use puremvc, I really don't understand how you understand this in turn as "view knows everything about mediator, while mediator does not know View", because it is clearly written on the official instance. It is estimated that mediator is used as a communication module class. However, if you discard the view code separation feature of mediator and only use it for communication, at least keep the original communication function so that mediator can still directly access the view. Otherwise, since mediator is used for communication, it cannot operate the view, and the result has to try to communicate with the view again ...... Puremvc requires that "view does not know mediator at all" to replace mediator without modifying the view. However, there are not many such requirements (most of which are to replace the view without changing the mediator, this should be solved by using the interface or condition Judgment), so we can relax the point so that they can reference each other, so that the communication between the two can be smooth. Puremvc implements "view without knowing mediator" by using mediator to directly listen to mouse events of a certain component of the view. You only need to listen once and do not need to transmit messages. When a mediator exists, there should be no communication-related view according to the standard view of puremvc, that is, the external logic.