Starting with Model/View/Controller (MVC) Architecture Pattern

 With  the massive advent of Internet, mobility and other network technologies, distributed programming is more popular than ever and it's unimaginable the idea that stand alone applications can come back

 

They are gone

 

So immediately a coupling crisis appeared in distributed applications: how to avoid mentioning concrete technologies in order to keep the maintenance of distributed systems in acceptable levels of complexity. For instance, how to avoid code twice (or even more than twice) large portions of formerly desktop UI, if we need to add a web channel for home consumers, a mobile channels for executives during business trips, etc. How to provide a solution not tied to a specific database (SQL Server, Oracle, etc) or,  even more, able to handle small sets of data via an XML-based repository

 

Model-View-Controller (most referred as MVC) is the name of one of the most successful architecture patterns, which address this issue. It consists in a separation of three application concerns in different logical tiers

 

• The user interface (UI), that receives inputs from the user and exposes results. In this schema is referred as "the View" , and it could be applied to the most basic text terminal, or the most advanced Pocket PC. The code of this tier deals with the specific available UI technologies

 

• A tier were domain entities "live", and their status is kept, usually known as "the Model" . It can be a database, an XML file or a whole mainframe system (accessible through communication technologies varying from propietary solutions to open standards like web services

 

• And finally, a nexus between the View and the Model, capable to react to events from the View, transforming the signal in a request for the model. Clear examples of this: a button click motivates a purchase invoice printing. The tier which handles this transform is called "the Controller" and basically contains use cases logic

 

The first benefit of this decomposition is the fact that the View and the Model are no more coupled. And with this, we can append more channels to our application (ATMs, etc) with no impact in the data access logic. Or conversely, we can change or extend the data repository with, for instance, aggregation services, immediately available for every channel at the same time

 

There are several uncoupling degrees of MVC in practice. Still the View can stay coupled with the Controller or vice versa, and the same applies for the Controller and the Model

 

So the question, again, is… where to start from?

 

And the answer again is: from Joe Hummel

 

In his second webcast in the series "Modern Software Development: Use Visual Studio 2005", he starts showing how Visual Studio 2005, although being a very productive tool from the perspective both the developer and the business, it imposes "its" architecture. And architecture quick, easy to understand, but not so easy to extent

 

So he revisits the MVC pattern, unleashing there some popular GoF patterns embedded (those are abstract, low level patterns compiled in a book that is still a best seller; its author are known as "the Gang of Four" or simply GoF, and so the term "GoF patterns")

 

Hummel explains very clearly how these patterns enforce the whole MVC architecture, and applies them to the raw initial outcome that Visual Studio 2005 produces loosing, as the patterns go by, the coupling among the three layers

 

Still better, the author recommends when/where not to use them, in order to not to over design the application. This could increase unnecessarily its complexity… and its later maintenance

 

Hummel concludes by mentioning two MS application blocks to put this concepts in practice in a productive and elegant manner (unfortunately because of a matter of time, no demos are offered)

 

So, go for a coffee, seat comfortable, turn up the volume and start watching

 

Architecting Desktop Applications with 2.0: Design Patterns for GUI Applications

 

Enjoy it!