I happened to see two discussions on ExtJS forum (
here and
here) about how to organize large Single Page Application. ExtJS 4.0 introduce
a MVC framework, which is similar idea as I mentioned about one year ago in my blog "
We don't need MVC framework on the server side today". Implementing a MVC framework on browser side is good idea for organizing team work on a big Single Page Application. But, one obvious cost is that you are going to stick with it if you use a specific MVC framework, for example this new MVC from ExtJS 4.0. Also, it brings in extra learning curve for any new MVC framework.
MVC is a well known term for application developer. I know MVC when Struts is released more than ten years ago. However, MVC has been invented much earlier. Later, I was aware that Swing uses MVC. MFC use MVC too. I think a concept need to be cleared when we have so many things implemented in MVC pattern.
For my opinion, all these MVC implementations can be classified into two groups: desktop application MVC and Web application MVC. For example,
Swing and MFC are desktop application MVC. Struts, Spring, Zend Framework are MVC implementation for Web application. Or from an other point of view, we can say desktop application MVC implementation is on the GUI component design level. And those MVC framework for Web application is on the application architecture design level. The selection of design pattern will affect how to organize team work on a big application. ExtJS 4.0 MVC is a Struts style MVC framework for pure client side programming. We say Javascript library like ExtJS let us be able to easily create a Single Page Application looks like desktop application. Now, ExtJS 4.0 introduce a Struts style MVC as its application framework. Will it really make code easier to main and better team work organization? I am afraid it is not true.
Back to those discussion in forums, those great detailed discussion are about how to organize a big single page web application. People all talk about MVC and intend to implement their own MVC framework. The interesting thing is, if we will treat our web application as Single Page Application, which kind MVC we are going to follow, the MVC for desktop application or MVF framework for Web application?
Let's have a look at MFC's document/viewer architecture diagram (
linked from microsoft site). MFC declares it is an implement of MVC but the document contains both Controller and Model. I think Swing is designed in similar way. But Sun Microsystem names it as
modified MVC.
Figure 1
For MVC framework for the Web application, I do not put a diagram here as it is well known to Web developers. Those framework always have a clear definition of Model, View, and Controller. The difference is that some controllers use configuration file to link View and Model, for instance Struts; Others use name conventions to link Model and View, for example, Zend Framework.
Now, we are making a Web application. And, we are developing a Web2.0 application, which looks and behave more like a desktop application instead of traditional multiple pages Web application. So, which type of MVC we should follow? For my opinion, it is good to follow the MVC design pattern employed in desktop application development. Since we all say modern Web2.0 application looks more and more like desktop application. What is the reason for us not to use methodology that have been successfully used for decades?
Before go to further discussion, I want to say something about Ajax library first. When Ajax became hot in industry in the past years, we saw many Ajax products in the market. They all declare that they are Ajax. But, according to my understand, these Ajax libraries can be divided into two groups: pure Javascript library running in browser only and those framework generates GUI widgets on server side. Personally, I do not like generating GUI widgets on the server side as it mixes many things together. It is messy and not flexible. I like libraries such as ExtJS, JQuery, and Dojo etc. I like them because using these pure Javascript libraries allow us implement a simpler and more scalable architecture than using one specific server side Ajax library can do. On the following picture, I present two ways of assigning tasks to Web developers. With pure Javascript Ajax library, we can assign in way (A). However, if you choose a server side Ajax library, you can only assign job in way (B). I like (A) as it means that I have real professional programmers who can focus on area, which they are professional and enjoying. And, method (A) implies that Javascript programmers do not need to care about what language server side uses. In the other words, server side programming language can be easily changed.
Figure 2
OK, now, suppose we select a pure client side Javascript Ajax library (group of awesome GUI widgets and more) for our Web 2.0 application (most likely an enterprise Web application instead of a public web site), where we will put our MVC? Well, I think we will have more than just one MVC here. Since I treat my Web application as a desktop application, I will go to MVC style employed by MFC or Swing. So, where will the MVC be in the architecture? Let's have a look at the following diagram.
Figure 3
As we can see, I present two different architecture designs in above picture. The whole application is composed by multiple modules. Each module may employee MVC inside. The MVC used here is something like modified MVC implemented in Swing and MFC Document/View architecture. For example, in ExtJS, don't you think the Grid widgets and Store can regarded as View and Document in MFC or View and Modal in Swing? But, in the application scope, can we use MVC too? Certainly we can. ExtJS 4.0 MVC is exactly the one. But, I believe that using modular programming concept will make things simpler than using MVC concept on this level for a "desktop application". I made my conclusion as described in above diagram. There are two ways to design the Web applications into modules. (A) represents a way to allow each module has its own interface and protocol to communicate with server side application for data. (B) represents a way to have a central proxy in Web browser to serve as a broker for two way data transfer. I prefer design (A) as it delivers an architecture design giving a clear ownership of module developing. That is, tasks can be assign to developers and they can work parallel.
In Figure 3, design (A) actually presents a Matrix modularization. It contains not only client side GUI function/feature module but also server side data service provider. Investigate Figure 3 with Figure 2, I will say that (B) in Figure 2 divided Web application into matrix modules. But, it assigns one matrix modules to one / one group of developers. I think the best way will be modularize the Web application in a matrix modularization way and assign tasks based on strategy presented in (A) of Figure 2. Modern Ajax libraries like Dojo, ExtJS and data delivering/representation techniques like RESTful Web service lhas make this kind design to be simpler and more scalable than others can do.
About the main application in the diagram. Its functions are more about initializing and destroying each module during their life cycle. It looks a little bit like Controller in MVC architecture. However, it is not because it mainly does two tasks,
- Load/unload modules. Looking into discussing threads mentioned at the begin, those functions like dynamically load sub application (module) should be implemented in this main application (entry application).
- Support a message/event passing architecture. A event publish-subscribe architecture is good for connect each module because it make interface among module simple and flexible.
So, according to my understanding, for a pure Javascript framework like ExtJS4.0, it actually used MVC on its widgets level already. It really makes thing more complicate when ExtJS 4.0 introduce another level of MVC design. Using modular design pattern for large Single Page Application is more nature way. It make the system design simple and task assign in team work easier and clearer ownership of coding.