MVC

MVC is Model View Controller, one of many ways to structure programs and applications. Some parts are obvious while others confusing. Everyone using MVC has a favourite variation and blindly accepts a lot of inconsistencies. Lets look at the theory and some actual practice.

The semantic Web

Semantic is a fashionable buzzword around the Web and is good in intent with many parts still evolving. Think of the semantic Web as someone inventing penicillin to cure people of horrible diseases but at a time when people are still trying to invent a usable syringe to inject the penicillin.

The semantic approach requires the separation of data from the presentation of data for at least three important reasons applicable today.

First, visually impaired people can change the presentation of data to fit their range of vision. As an extension of visual impairment, people with smartphones and Apple products, iPhone, iPad, iProfit, can change the presentation to fit a very small screen.

Second, search engines and other applications can access the data without processing all the decorative stuff.

The third reason, the one still under development, is the addition of data to identify the meaning of data, commonly called metadata. There are lots of ways to add metadata, not much agreement on what you need or what is useful, and very few applications that can use all the metadata.

In the web we can separate presentation from the data by taking all the decoration out of the HTML and placing it in CSS. The CSS can be downloaded once and cached in the Web browser, making your Web site faster and the Web more efficient.

The MVC equivalent is the View. The view formats the output without any programming. To be more specific, there should be no programming related to business logic, application logic, or data conversion. The advantage of the View is the first step towards separation of presentation. The problems with the MVC View are the impossibility of building the ideal view and the fact that a view is obsolete.

Back in 1999, when Microsoft invented a major leap forward in Web technology, MVC became obsolete. HMVC is a theoretical step forward to help MVC survive this century but 13 years later there is still no agreement on HMVC.

Model

Some people classify the model as the database. Application ends up in the controller. Most people do the reverse, they put all the business logic in the model and the controller is just a skinny bit selecting the next page to be displayed.

Zend Framework documentation on the model says:

Data access routines and some business logic can be defined in the model.

If you follow the Zend advice, where do you put the rest of the business logic? Why spread the business logic over two areas?

Data usually has relationships, some relationships are part of the business model, and some relationships can be placed in a database. If table ABC has rows identifying invoices and table ABCL contains line items for the invoices and you are using the PostgreSQL database, you can tell PostgreSQL to treat rows in ABCL as children of ABC. Some simpler databases do not let you define relationships. Either way, you model has to understand the relationships.

When someone types in the data for an invoice, they type in the invoice level details then one or more line items. The controller has to know the difference between an invoice and a line item to display the right view, the invoice entry view or the line item entry view. The controller has to know how to switch from the invoice view to the line item and how to switch back when the line items are complete.

Business logic might be involved in the controller decision. Your invoices might require at least one chargeable item plus a matching tax item. Your invoices might require a delivery charge line item even if there is no change. These are your business rules imposed on the basic data structure of an invoice.

View

Look at some example view problems. You have an application displaying money. Should the money amount be formatted in the business logic or in the view? If you work in only one currency, it could be formatted in the view. In some countries a thousand dollars will be $1,000.00 while some Europeans prefer $1.000,00. The view could decide based on the country selected in the profile of someone who is logged in or based on information passed in by their Web browser.

Now expand the currency problem. Process multiple currencies. The business logic has to know the type of currency for an amount. If the amount is processed in the view, the view has to know both the currency and the country of display.

Lets make it more complicated. Your currency might be dollars and cents with two digits displayed for cents. Tax calculations might be made to fractions of a cent then rounded back to cents at the end of the calculation. When you display calculation rates and intermediate amounts, the view would have to know enough to display the right number of digits. An intermediate tax calculation amount might be $35.6745 where the last bit is a fraction of a dollar, not cents.

Try explaining the difference to a view. Try explaining it to a view so the view can send out the data wrapped in HTML with no presentation information and attach the right CSS.

The typical approach is to process currencies outside of the view to ensure they are correct and to process country level display requirements because they are wrapped up in language processing. You might set up one view for left to right language display and a separate view for right to left. Separate views have the advantage that different people can work on the views.

A view should contain presentation, not data, but many views contain data. They contain the text displayed on a page. When the Web site owner decides to add German to an English language Web site, he/she suddenly finds large parts of the data (the content text) is written into views. There will be a huge cost of moving the text (the data) from the views to the database.

Then the web site owner decides to add Mandarin. Suddenly the text has to be displayed in a different format. Do you use one view, pass the language information, and let the view work out how to present everything or do you create different views?

There are more complicated parts of views. Multipage form handling can be part of the view if it is simply one form over several pages. What do you do when the answers on one page decide which pages should be displayed next? Selective display is business or application logic and should not be in a view.

Lists can be displayed, paged, and sorted in a view without using business or application logic. Sending a default selection from a user’s profile to the view is still acceptable. What do you do when you want to save a user’s selection back to their profile? What do you do when their selection is used to control another part of the application? Again you have part of the view interacting with the data in a way that really should be business or application logic.

Zend Framework documentation on the view says:

Views define exactly what is presented to the user. Usually controllers pass data to each view to render in some format. Views will often collect data from the user, as well. This is where you're likely to find HTML markup in your MVC applications.

HTML can be used to indicate markup (presentation) or structure. Structure is best produced as XML. XHTML makes the most sense for structured data set to a view because the structure can be presented with the addition of CSS and no further processing. If you want to sort a table of data and the table is in an XHTML tble, the user can sort it in any sequence with some Javascript. That is the important bit when thinking about HTML markup instead of HTML.

Some people impose a rule that all HTML must be in the view and nowhere else. They then have to select a way of passing structured data to the view and argue over what is acceptable.

Controller

Zend say:

Controllers bind the whole pattern together. They manipulate models, decide which view to display based on the user's request and other factors, pass along the data that each view will need, or hand off control to another controller entirely. Most MVC experts recommend keeping controllers as skinny as possible.

There are MVC frameworks where nothing happens in the controller. The controller asks the model what should be done next. The model might redirect to a new page.

In the next level up, the controller decides navigation. The controller knows page AA can go to page BB or CC depending on a user selection in a form. The controller can look at the request and make that simple decision.

Then you add editing of user input to the form on page AA. The reply from AA has to be validated in the model before the controller can decide which page is next. There might be a requirement to redisplay AA with error messages. Suddenly it is easier to put navigation in the model. You are back to nothing in the controller.

Layers

Layering software makes sense because an application can be split into several areas for development by specialists with different skills. The view makes sense as a layer if it has a narrow range of code.

View layers can have the formatting instructions in an XSL layer and the programming code in another layer. Assume the Web scripting is written in PHP. There would be a programming layer maintained by a PHP programmer. An XSL expert could work on the XSL. XSLT, the transformation part of XSL, is a type of programming that is half way between the procedural thinking of PHP and the non procedural thinking of CSS. Splitting the work between two brains is a good idea.

When you layer the view into programming and presentation, you effectively have a controller layer and a view layer within the view.

The model can be split into a database related layer, a data related layer, an application layer, and a business logic layer. The database layer is usually called a database abstraction layer and gives you some freedom to use other databases. The other layers give you other freedoms.

The data layer attacks problems along the lines of the invoice/line item problem. You sometimes want to treat an invoice as one object, including the line items, and not worry about the way it is stored in the database. The data layer can do that. The data layer can return the invoice with the customer data attacked, the currency and tax rate attached, whatever level of information you need. The data layer can also save changes with the updates minimised to just the database rows that change.

An application layer might calculate delivery charges in several ways. The business layer might decide when a delivery charge is applied and when delivery is free. The business layer might be changed by the company accountant in consultation with the sales manager and other people. The application layer might be maintained by the people supplying the application. The people supplying the application might build their part into programming code for speed. The business layer should have everything stored in the database with update forms created for the accountant.

Frameworks

Read about frameworks in Web development frameworks. Most frameworks have some sort of structure that fits into an MVC style. Some frameworks let you decide what you put in the model, the view, and the controller. Some frameworks define exactly what goes into each area. The right framework for you is more important that the fine details of what they put where.

Conclusion

The View part of MVC is required for the semantic Web. The rest of MVC is so variable that it is almost irrelevant. You are better off choosing a development framework and using the structure built in to the framework.