A New Way To Think Of MVC. Introducing PBVC.

Yesterday I argued that companies need platforms in order to maximize their flexibility to respond to the demands of the market in the fastest possible way. Today I thought that many of you could perhaps benefit from from some more specifics. 

When you think about developing an application, many (most?) of you will think of implementing some version of the MVC design pattern which stands for Model View Controller. The MVC pattern specifies a way to separate the user interface (View) from the data (Model) using a messaging or event system routed through a Controller. But the MVC can be implemented in many ways, and the key to a good MVC implementation is what exactly the model is.

The model essentially represents your data. But does it represent data in a form that just reflects how you store the data in the database, or does it represent data in a form that reflects what makes most sense in the context of what your application is trying to do. When the later is the case, we call the data representation business logic.

Business logic typically handle requests for data by grabbing raw data from a database, modifying or combining that data with other data, and presenting that data in a way that would be most useful to the user interface code because it reflects the real application model instead of just how the data is stored in the database.

And so here we get to the core of what I am suggesting.

When I talk about the idea that companies need platforms, I am making a really specific argument about how to architect systems. What I am really suggesting is that the model be split into a platform, and business logic. The platform is designed to make it easy, or easier, to build and modify business logic.

What this means will be different for every company. But, to use a simple example, if you are a retailer, then perhaps the customer database, and the credit card transaction system are handled at the platform level because they are things that should always be the same no matter what. At a lower level, perhaps the platform also contains a data storage abstraction that handles all scaling.

Scaling is a great example of something that should never be of concern to someone focused on business logic. And the business logic developer should rarely be told that something can't be done because the system can't handle it, can't scale etc. The platform developer should be totally focused on serving the needs of the business logic developer by providing abstractions of core system functions and application requirements.

What we are really doing is adding one more layer to the MVC pattern. Instead of MVC, think PBVC, for Platform, Business logic, View, Controller. And while, on some level, this many seem obvious, the frameworks that many of us use do not suggest this level of granularity. And so while no MVC frameworks prevent this kind of layering, because of where frameworks stop, most developers will fully blend things that are platform related issues with things that are business logic, making code much harder to scale and maintain, and most importantly, slowing down reaction time in the marketplace. For many businesses that intend to scale and need to iterate rapidly, separating these two different layers and focusing on them independently can have a profound effect on the ultimate success of your business.