What is MVC, Really?

In 1979 (or so) Trygve M. H. Reenskaug began work on a new software pattern he would call “MVC: Model View Controller”. The concept was designed around a language known as Smalltalk and was meant to solve the problem of how to segregate the various parts of an application. But you should read the original document instead of me trying to summarize it for you.

Wikipedia has a nice (long) description of the MVC pattern but it’s not all that concise and clear. But than again, not many writings on software topics are. The more you read on the subject of MVC, the more confused you may become; I know that’s what happen to me as I began my journey down this dark road. I can well imagine that this piece is not the first you read on the topic, after all, Google has 16 million results on the topic, many written my accomplished authors and noted software authorities. (I really like this one.)

I’m not going to bore you with my definitions, explanations or point of view. Do the Google search, read several (dozen) of the sites around the net and come to your own conclusions.

An Introduction TO MVC

Bluewater MVC uses a modified MVC pattern, one focused on web-based applications and that is what this article will focus on.

The View Pattern

The View Pattern is a common thread among articles on MVC. Everyone seems to agree that the View is simply a means of information display; whether to just give answers or ask questions. Bluewater relies on PHP/HTML based templates (you can use Smarty, or any other templating system, if you like) to display information, and in a typical web application fashion, uses HTML forms to ask questions of a user.

Data is assembled and given to a View template for presentation. Any response form the user is then handled by the other segments of the pattern for further processing. Think of the View pattern as simply the waiter handing you a menu an taking your order back to the kitchen.

In many respects, the View Pattern in Bluewater MVC resembles the “model view presenter” pattern. Meaning the View is more of a data presentation layer than anything else. The Browser handles all the user interaction events, along with any Javascript the site may use, while the [x]HTML (HTML5) is simply a construct mechanism for the actual content as defined by the Controller and retrieved by the Model.

Again, a web-centric POV for MVC Patterns. Also keep in mind that this is not only used for PC based browsers but can be factored to utilize web-enabled phones, PDAs, RSS feeds, SOAP requests, etc. All the same data set, just different ways of presenting it.

The View as Content and Presentation

The Controller Pattern

The Controller Pattern handles the decision making, data restructuring, and acts as a go-between for the View and the Model components. This is where some theories on MVC diverge. Within Bluewater MVC quite a bit of the business logic resides within the Controller; what to do here and there; what to do if this or that.

The Controller does not know anything about how the data is accessed, stored, retrieved or even how various pieces of data might be related to each other. The Controller is just what the name implies: it controls, it asks for data format the Model, re-factors the data into a format the View can understand and then decides which View to call to present the data to the user.

The Model Pattern

The Model Pattern sits on top of the data access layer, which is responsible for the access, update and modification of the raw data. It is the data access layer that does the actual communication with the data storage mechanism; which could be any number of databases or even a file based storage system.

The Model Pattern concerns itself with the portion of the business logic that determines relationships between data points, meaning behind data sets, etc. The Model understands record set objects as dictated by the data access layer. These objects are then converted into data objects for access by the Controller and View Patterns.

The Battle Between Application Logic and Business Logic

This is an age old conundrum. What constitutes application logic and what really is business logic? I answer it this way: If the data needs to be interpreted to understand that a person will be 35 years old in 15 days; that’s application logic and it goes in the Model. If a decision is made based upon the age of a person; that’s business logic and it goes in the Controller.

You may read many articles on this topic and they will disagree with this assessment (but many will agree!), but the thing to keep in mind is what are you doing with the data at hand? Making conversions and associations or making decisions.

Der Kampf zwischen Anwendungslogik und Business Logic

Dies ist eine uralte Rätsel. Was macht die Anwendungslogik und was ist wirklich Business-Logik? Antworte ich es so: Wenn die Daten interpretiert werden muss, um zu verstehen, dass eine Person 35 Jahre alt sein, in 15 Tagen; das ist die Anwendungslogik und es in der Modell geht . Wenn eine Entscheidung getroffen wird, basierend auf dem Alter einer Person; das ist die Geschäftslogik und es in der Regler geht.

Sie können viele Artikel zu diesem Thema zu lesen, und sie werden mit dieser Einschätzung einverstanden (aber viele werden mir zustimmen!), Aber die Sache im Auge zu behalten ist, was machen Sie mit den Daten auf der Hand? Umrechnungen und Verbänden oder Entscheidungen zu treffen.