Roots of MVC

Bill Sheldon — Mon, 15 Oct 2007 13:56:00 GMT

So the latest industry buzz-term (since it's not a word per say) is MVC. MVC is a description of a software pattern. The key to software patterns is being able to speak them and understand them. I'm sure you've read many articles that mention MVC and you sit there wondering: What is MVC?

So some 'jerk' (you know the type who provides your latitude and longitude when you ask where you are) says to you, "MVC stands for Model-View-Controller and it's the latest in architecture."

OK, What is a Model View Controller and what do I need to change in my architecture?

This is actually a pretty simple question and as I've said before, outside of major paradigm shifts - the more things 'change' in the technology world, the more they stay the same. Many years ago - probably before some of you reading this were born we had the concept of a 3-tier architecture. The idea, which followed on the heels of modular programming was that you should separate out your User Interface from your Business Logic from your Data Access. (UBD... or reordered DUB) Over time this was called n-Tier because you might have more then one 'tier'. The idea however was that you had components responsible for these elements.

Well in an MVC model the Model represents your data access, the View represents your User Interface and the Controller represents your Business Logic. So you have DUB -> MVC - but wait say the formallists, it isn't the same. So what's the difference?

Well under the n-tier model there were those who subscribed to the idea that all communication had to travel from the User interface to the Business Layer to the Data Tier, and in the reverse. In other words the User Interface wasn't allowed to directly communicate to the Data Tier. We tended to refer to people who tried to enforce this as 'jerks' (see above). Generally those of us developing applications spent hours justifying the fact that in the real world it made sense to have the User Interface directly access the Data tier to retrieve key data and in some cases even for certain key automated updates. That's essentially the gist of the difference.

So there you have it because people couldn't adapt to this one concept we have a new name - MVC to describe an old concept. So when someone suggests you re-architect your current n-Tier application to be MVC based and they want to charge you money to do so - well you know how much it should cost - nothing because even if you kept your UI from updating database directly, you still have an MVC architecture in place.... now you can just stop being so * retentive about which components in that architecture communicate.

Its funny we literally created a new name for an old concept, why? Well the 'jerks' will accept a concept with a new name that doesn't exactly match their understanding of an older concept. It's literally easier to reaname and remarket a concept then to for some people to update their knowledge.

The preceding is of course a brief comparison - to wit there are several other characteristics of the architecture models I've omitted (such as n-Tier) in order to quickly illustrate the key similarities between these models. I'm sure someone (see jerk above) will point out one or more such items in the comments...

UPDATE: I should also point out that yes the MVC pattern has probably existed for as long as the 3-tier architecture has. The point here is that it is the latest trend for architects and for many the new description seems like it is describing something... well.. new. In the past MVC was a common model for application logic but now that more "software architects" are actually learning about software best practices it has made the move to describing enterprise architecture. The concepts aren't new, just the name being used to describe what we've been trying to do.

The Next Application Paradigm - OBA

Bill Sheldon — Tue, 14 Aug 2007 17:23:00 GMT

So in the past I've written articles that talk about how the web as an application model is peaking for certain types of application models. Specifically that while the 'reach' of web applications - ie. the way that even now I can be sitting in a Del Taco in Riverside (where it is 108 degrees farenheit) updating my blog just prior to heading over for a user group meeting, provide a powerful paradigm. This isn't going to disappear and isn't to be discounted, but it isn't enough. New technologies such as Silverlight and WPF will help extend the life of the web as a UI, but the reality is, web services allow me to use a rich client vs. a web site for editing my comments and then just submit the data to the server.

Most enterprise applications (as opposed to public facing) continue to be rich client applications. In the future there will still be many such applications which are written from the ground up, expecially those which are focused more on sizzle then steak. But I feel that the new paradigm for actual business applications will be to leverage someone else's User Interface for much of the framework with a minimalist custom set of controls. A couple years ago the common 'UI design pattern' we heard from smart client customers was for them to ask for a user interface based on Outlook. This is still the case but things are shifting, you see instead of asking for a client based on Outlook - instead we are starting with Outlook as the client and just customizing it for the needs of the organization.

Visual Studio Tools for Office (VSTO) have been around since .NET 1.x but as I have been informed many times - haven't really taken off as some expect. However, like so many things, until the rest of the infrastructure to support a technology is in place even a great tool gets only limited use. In the past VSTO has primarily focused on the document. Specifically it started as a replacement for VBA and the document centric customizations of VBA and Macros... but with Office 2007 and Visual Studio 2008 (Orcas) - well this isn't the same model.

An OBA is an Office Business Application, in short it is an architectural model which leverages the full Office System to implement custom business solutions. The first key enabling technology is of course SharePoint aka Microsoft Office SharePoint Server 2007. I'm not a big fan of SharePoint as a development platform, but as a host for documents and document templates it is unparalleled. By marrying key document templates with a web site you gain the benefit of a web application with a rich client. I'll post more in the future on some of the key enabling technologies which can then be built on this - think about Add-In's and custom message contents but the key is now that we have a solid server combined with a host of new tools the OBA model leveraging VSTO is a very viable solution framework.

Don't think so - well take a close look at Team System. Team Explorer is in part an OBA, yes there is a 'custom' add in for Visual Studio which isn't part of Office - however, I know for a fact that when I start working with tasks, work items, bugs etc. in TFS I do it all with Excel. Why because Team Explorer's custom interface pieces aren't natural to me, but the add-ins for Excel and the way that the forms are hosted on SharePoint and retrieve and update data from SQL Server provide me a user interface which is effective. So when you are thinking about how to engineer that next big smart client application don't discount the value of being able to leverage the Office System as the plumbing for much of what you'll do.

Tonight I'll be presenting on a demo OBA solution which InterKnowlogy helped Microsoft develop to highlight some of the new features of VSTO 2008. This is a powerful architecture and I'm expecting to do additional presentations similar to the one I'm doing tonight for the Inland Empire .NET User Group. I grabbed a screen shot of their homepage describing tonight's presentation iedotnetug_org.JPG (172.5 KB) but feel free to visit their site (http://www.iedotnetug.org) or stop in for a meeting in the future.

Architecture

Roots of MVC

The Next Application Paradigm - OBA