Back then, there weren't any sophisticated MVC tools in Visual Studio, the closest was the Smart Client Software Factory (SCSF) and Web Client Software Factory (WCSF), but both were using rather complicated implementations. But today, VS 2010 provides us with ASP.NET MVC web application templates which effectively raises the need to answer the integration question even further.
Before I discuss the integration ideas, I would like to first share with you my personal perspective of the MVC architecture. Firstly, MVC is an out-dated (but good) architecture. Many sites will tell you that MVC is not new and it has been around since SmallTalk. Why I say it is out-dated is because it was not designed for today's service-oriented distributed architectures (something that can be fixed when merged with Layering).
Secondly, I view MVC as a "micro-pattern" for developing UI applications and Layering as a "macro-pattern" that can house multiple micro-patterns (not just limited to MVC). Therefore, I truly believe that MVC can be integrated into Layering to leverage on modern day distributed environments.
Finally, I felt that the out-of-the-box ASP.NET MVC templates in VS2010 are encouraging a monolithic approach. Ok, I admit that I think most of the OOTB VS templates are *evil*, simply because their focus is on RAD and promoting the adoption of a specific technology without looking at the complete architecture. Some developers have already realized this and have started to decouple their Data Layers to a Data Service, but that still leaves them with a "client/server application" at best. Do take note that all these problems I highlighted are not the fault of the developers but more on the project templates.
I shall reserve my ideas to fix those templates to another post, but right now, I will provide the high-level concepts of merging the two architectures to get the best of both worlds. There are two models which I have came up with and I will start off with the first one which I conveniently termed it as the Bridged Model.
If we dissect both architectures, we can easily identify components of similar responsibilities regardless of the term that is used. In MVC, the Model is used to ferry data, the View is used to display/capture data and the Controller is used to process logic and co-ordinate the flow between Views. In Layered Architecture, the Business Entities are used to ferry data, UI Components are used to display/capture data and the UI Process Components are there to co-ordinate the UI (and connect to the service back-end) - Notice the similarities?
In the Bridged Model, the key to connecting both architectures lies in the Controller component of the MVC and the UI Process Component (UIPC) of the Layered Architecture. By connecting the Controller to the UIPC, we treat the entire MVC portion as a UI layer (or component) sitting on top of the UIPC. This strategy has the benefit of making the Controller more lightweight as most of the application and service-communication logic is delegated to the UIPC. It is also good for multi-UI platform applications which may allow Desktop, RIA and mobile clients to share the same UI processing logic.
If you are integrating a MVC web application to an application with existing UI components calling a service back-end, then the Bridge Model will make most sense.
While the Bridge Model works in connecting the two architectures, it may seem less elegant if we only have a single UI platform. In that case, we may not want the performance overhead of the Controller-UIPC relationship and to remedy it, we can adopt the Integrated Model.
In the Integrated Model, the Presentation Layer components are being replaced completely with the MVC components. The responsibility of the UIPC is unified into the Controller, eliminating one level in the UI and therefore, improving the performance of the application.
Whether to use the Bridge Model, Integrated Model or not at all, is depending on your choice and the projected application growth. If you are dead-sure that your application will not grow, then the monolithic approach presented by the OOTB templates will work just fine. Otherwise, if you share the same thoughts like me i.e. "All applications has the potential to grow, no matter how small they are", then it may be wise to look at the integration models from the start.
Take note that although I used Web Application in the context of the discussion, these concepts can be equally applied to any type of MVC application i.e. the SCSF implementation of MVC/MVP.
[Update: You can now get a sample of MVC integrated to Layered Architecture here]
No comments:
Post a Comment