[Flash pragmatism] MVC in Flash

Flash
Differences from 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.

 

 

 

Differences between as3 and traditional languages:

 

• As3 is a single language environment, and the problem of Multi-Layer Code mixing is not that serious.
•
Normally, as3 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.

• The events and dynamic features of as3 are duplicated with the functions of some frameworks.
• The current framework of as3 is immature 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:

 

 

 

• There is a relatively usable debugger. debugging is troublesome when the framework is used, mainly because of the increasing number of single-step debugging steps.
• Impede the use of IDE functions. Use flex
For example, you can jump to the specific implementation of the specified method by pressing CTRL + clicking (F4), and jump to the location of the method to be called by searching the reference panel from the implementation of the method. After the framework is used, these functions will become invalid.

• Features related to the flex framework 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 will impede 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.
Interface) is similar to the previous structure. Other components, such as maps and characters, cannot apply the MVC Framework in any way. First, the efficiency cannot be achieved. 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?

 

 

 

This makes flash less suitable for using the MVC framework than in general.

 

MVC cannot be implemented without using the existing framework
Since I am talking about the poor framework. So we don't need a framework. What should we do?

 

 

 

In fact, if you just want to Implement Model View
Controller) is only 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 placed in a fixed position. The reference of the view is stored in static properties or managed in management classes. commands can be directly initialized and executed as functions or classes, or reflected. 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 implement a simple communication framework and provide necessary functions, if necessary. This is totally different from the cost required to use some specialized MVC frameworks.

 

 

 

However, my opinion is that MVC is a very good architecture model. We recommend that you try it for any project, but be cautious when using the framework.

 

 

 

For the simplest MVC, we have recently seen a very confusing example. However, this example is helpful for everyone to understand 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, the command only cares about the view and model related to itself, and no one cares about the model, this is consistent with the decoupling goal in general cases. Although this is not completely decoupled, it is at least achieved in terms of ideas and logic separation, but there are only problems in collaboration, such as the inability to implement free parallel development, this addition of simple reflection can also be solved.

 

 

 

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.

 

Should framework be used rationally?
Programmers are science students and should use science students to 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 who do not even have a framework, the project is still finished because I have used the framework and fail to use it, I am speechless.

 

MVC Framework recommended
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 did not use flex.
Framework can be used naturally.

 

 

 

For the robotlegs tutorial, see the following:

 

Http://wenku.baidu.com/view/42a08b235901020207409c60.html

 

 

 

I 'd like to remind you that although I think robotlegs is very convenient and interesting, it is not used in projects because my projects are not large and it is a game. 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.

 

Even using the MVC Framework does not require full decoupling.
Decoupling 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, directly Coupled
Set the value of the view in window1, instead of sending a message similar to refresh_window1, because the name of send_data_to_window1 is determined to be specific to this view. If it does not operate this view in the end, is there a problem?

 

 

 

Decoupling and decoupling, but the results are not coupled for a module that has a sense of connection, 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 the best scalability only turns your programs into a mess. It is just a proper amount of coupling that the program can have a definite form and it will not be confusing.

 

General misunderstanding
In fact, there are few people who use the framework, especially those who have low levels of actions.
Among the script developers. 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.

 

 

 

• MVC is used even if message communication is not used
Message Communication is only a method. If you only use the communication function of the framework to send messages between views, and discard all other functions, it is better to directly use events, there is also an MVC framework.

 

 

 

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.

 

 

 

• Since the MVC framework is used, it is not easy to figure.
It should be clear that 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.

 

 

 

• The mediator knows everything about the view. The view does not know mediator at all, rather than the opposite.
For those 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 the official instance is clearly written. 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 listening logic in the standard view of puremvc.

 

From: http://blog.sina.com.cn/s/blog_3ecb9b1101013r1f.html