Best MVC Practices

1. Model
2. View
3. Controller

Although Model-View-Controller (MVC) is known by nearly every Web developer, how to properly use MVC in real application development still eludes many people. The central idea behind MVC is code reusability and separation of concerns. In this section, we describe some general guidelines on how to better follow MVC when developing a Yii application.
To better explain these guidelines, we assume a Web application consists of several sub-applications, such as

• front end: a public-facing website for normal end users;
• back end: a website that exposes administrative functionality for managing the application. This is usually restricted to administrative staff;
• console: an application consisting of console commands to be run in a terminal window or as scheduled jobs to support the whole application;
• Web API: providing interfaces to third parties for integrating with the application.

The sub-applications may be implemented in terms of modules, or as a Yii application that shares some code with other sub-applications.

1. Model

Models represent the underlying data structure of a Web application. Models are often shared among different sub-applications of a Web application. For example, a LoginForm model may be used by both the front end and the back end of an application; a News model may be used by the console commands, Web APIs, and the front/back end of an application. Therefore, models

• should contain properties to represent specific data;
• should contain business logic (e.g. validation rules) to ensure the represented data fulfills the design requirement;
• may contain code for manipulating data. For example, a SearchForm model, besides representing the search input data, may contain a search method to implement the actual search.

Sometimes, following the last rule above may make a model very fat, containing too much code in a single class. It may also make the model hard to maintain if the code it contains serves different purposes. For example, a News model may contain a method named getLatestNews which is only used by the front end; it may also contain a method named getDeletedNews which is only used by the back end. This may be fine for an application of small to medium size. For large applications, the following strategy may be used to make models more maintainable:

• Define a NewsBase model class which only contains code shared by different sub-applications (e.g. front end, back end);
• In each sub-application, define a News model by extending from NewsBase. Place all of the code that is specific to the sub-application in this News model.

So, if we were to employ this strategy in our above example, we would add a News model in the front end application that contains only the getLatestNews method, and we would add another News model in the back end application, which contains only the getDeletedNews method.
In general, models should not contain logic that deals directly with end users. More specifically, models

• should not use $_GET, $_POST, or other similar variables that are directly tied to the end-user request. Remember that a model may be used by a totally different sub-application (e.g. unit test, Web API) that may not use these variables to represent user requests. These variables pertaining to the user request should be handled by the Controller.
• should avoid embedding HTML or other presentational code. Because presentational code varies according to end user requirements (e.g. front end and back end may show the detail of a news in completely different formats), it is better taken care of by views.

2. View

Views are responsible for presenting models in the format that end users desire. In general, views

• should mainly contain presentational code, such as HTML, and simple PHP code to traverse, format and render data;
• should avoid containing code that performs explicit DB queries. Such code is better placed in models.
• should avoid direct access to $_GET, $_POST, or other similar variables that represent the end user request. This is the controller's job. The view should be focused on the display and layout of the data provided to it by the controller and/or model, but not attempting to access request variables or the database directly.
• may access properties and methods of controllers and models directly. However, this should be done only for the purpose of presentation.

Views can be reused in different ways:

• Layout: common presentational areas (e.g. page header, footer) can be put in a layout view.
• Partial views: use partial views (views that are not decorated by layouts) to reuse fragments of presentational code. For example, we use _form.php partial view to render the model input form that is used in both model creation and updating pages.
• Widgets: if a lot of logic is needed to present a partial view, the partial view can be turned into a widget whose class file is the best place to contain this logic. For widgets that generate a lot of HTML markup, it is best to use view files specific to the widget to contain the markup.
• Helper classes: in views we often need some code snippets to do tiny tasks such as formatting data or generating HTML tags. Rather than placing this code directly into the view files, a better approach is to place all of these code snippets in a view helper class. Then, just use the helper class in your view files. Yii provides an example of this approach. Yii has a powerful CHtml helper class that can produce commonly used HTML code. Helper classes may be put in an autoloadable directory so that they can be used without explicit class inclusion.

3. Controller

Controllers are the glue that binds models, views and other components together into a runnable application. Controllers are responsible for dealing directly with end user requests. Therefore, controllers

• may access $_GET, $_POST and other PHP variables that represent user requests;
• may create model instances and manage their life cycles. For example, in a typical model update action, the controller may first create the model instance; then populate the model with the user input from $_POST; after saving the model successfully, the controller may redirect the user browser to the model detail page. Note that the actual implementation of saving a model should be located in the model instead of the controller.
• should avoid containing embedded SQL statements, which are better kept in models.
• should avoid containing any HTML or any other presentational markup. This is better kept in views.

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data. This is because the data structure and business logic represented by models is typically very specific to the particular application, and needs to be heavily customized to meet the specific application requirements; while controller logic often follows a similar pattern across applications and therefore may well be simplified by the underlying framework or the base classes.

Benefits and Advantages of HTML5 Semantic Markup for SEO

Why Should Developers Be Excited About Semantic Markup?

Semantic Markup is best defined as using special HTML tags that describe what kind of content it contains. In very simple terms: it offers you very clean code – something all SEOs and developers love.

To illustrate the advantages that HTML5 offers, consider how <h1> and <p> elements are used to differentiate separate kinds of text on a page. These <h1> & <h2> tags are critical to on-page SEO. They are on the top of the HTML markup food chain and theoretically should describe the current pages topic.

HTML5 takes semantics a step further with new HTML tags for larger portions of websites. Take a look at some of them below:

<header></header>
<nav></nav>
<menu></menu>
<article></article>
<section></section>
<aside></aside>
<footer></footer>

Most likely you can guess what some of the above tags should be used for on a web page.

If not, here is a very brief breakdown:

The <header> Element

The header element is used to contain the header elements of any block of related content. For example, the global header for a website that contains a sites logo and or navigation would be a basic example of where to use this tag.The <footer> Element

This element is used in the same way as the header element but for common footer elements of a block of related content. An example of this would be the utility links on the footer of a site.

The <nav> Element

This one is fairly simple but it can also be abused. This is intended to define major navigation areas on a page, and in most cases, will be groups of links. Be aware that just because several links might be in proximity of each other does not qualify the use of the <nav> element.

The <menu> Element

This element is similar to the <nav> element but is a more relaxed fashion. This element might be used to group together links that act as a sub-navigation. Another user would be for social media icons that link out to a site’s social media pages.

The <article> Element

This element is used for self-contained compositions of a webpage. For example, a list of your site’s blog posts each would be contained by an <article> tag. This can also be used for other types of content as well. Just keep in mind its self-contained use.

The <section> Element

The <section> element is commonly misused. Most people would think of using the section tag as a container block level element to contain a portion of the site. This is incorrect. The true way to use the section element is to think of it in terms of grouping specific portions of content. Inside a section you may have multiple headings to further narrow the focus of the section and there may be multiple sections inside a particular piece of content. Whew! If you find yourself confused by this (I know I was originally) then don’t worry. You can check out this article by Bruce Lawson for a more in-depth view of the section element : Prognosis of the HTML5 Section Element.

The <aside> Element

This is another frequently misused element. Most people think of this element as a sidebar container. A better way of understanding of how to use the <aside> element is by reserving it for tangentially related content outside of an article. One way you may use it is when you have a sidebar element that contains features a block of advertisement above a blogroll panel. The blogroll is tangentially related to the blog article but the advertisement block is not related to the article tangentially. Therefore, using an <aside> tag for an entire sidebar doesn’t accurately describe its contents.

So What’s the Big Deal for SEO?

This is not only easy for us to understand but also much easier for a Google Bot to crawl and index due to its clean markup. Traditional methods for defining header and footer containers consisted of <div> tags with unique id’s to target them with CSS for styling. While that is an effective way of doing things it is far messier than using specific tags for each area of content.

Look at the example below of how many current websites use <div> tags to create a basic two-column layout with a header and footer:

<div id=”header”>
<ul id=”nav”>
</ul><!-- End #nav -->
</div><!-- End #header -->
<div id=”content”>
<div id="blogpost">
<h1>This is my Blogpost</h1>
<p>This is my first paragraph.</p>
</div><!-- End #blogpost -->
</div><!-- End #content -->
<div id=”sidebar”>
<div id="blogroll">
<p>My blogroll Content.</p>
</div><!-- End #blogroll -->
</div><!-- End #sidebar -->
<div id=”footer”>
<p>My Footer Content.</p>
</div><!-- End #footer --> 

And below is the same layout using HTML5 markup:

<header> <nav></nav> </header>
<div id=”content”>
<article id="blogpost">
<section> <h1>This is my Blogpost</h1>
<p>This is my first paragraph.</p>
</section> </article><!-- End #blogpost --> </div><!-- End #content -->
<div id=”sidebar”> <aside id="blogroll"> <p>My blogroll Content.</p> </aside>
<!-- End #blogroll --> </div><!-- End #sidebar --> <footer> <p>My Footer Content.</p> </footer>

While the markup might not seem shorter it definitely is more semantic. The <div> elements in the first example have no semantic meaning outside their given ID attributes. Whereas, the second example uses the new semantic markup HTML5 elements to better describe the content and the overall layout of the page. This will be much easily understood by a Google Bot or a screen reader due to its logical markup.

And of Course…. The Drawbacks

Unfortunately, do to the lack of standardization between browsers currently these tags can be interpreted differently or entirely ignored all together. This most commonly happens in older versions of Internet Explorer. Luckily, there are methods to “teach” the browser what these new tags are in order to style them appropriately using CSS. Simply embed this script in the <head> section of your markup to enable the use of the new tags for older browsers:

<!--[if IE]> <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script> <![endif]-->

Without getting too technical, when the above jQuery script runs it creates new elements inside the Internet Explorer Document Object Model(DOM) so that it understands the new markup. Bottom line is that it works and that is all that matters to most people. The only qualm some people have regarding the above patch is that it is JavaScript dependent. However, the percentage of users who browse with JavaScript disabled has been on the decline for several years and is a very small portion of the overall users on the web.

MVC vs. MVP vs. MVVM

MVC: Three components – View (your UI), Model (your business entities / data – that view is displaying) & Controller (contains the logic that alters the model depending on the action triggered by UI, typically implementing a Use Case). It’s widely known that MVC is a compound pattern (View and Controller have Strategy implementation, View itself can be a Composite implementation & View and Model are synched through Observer). In this case Controller doesn’t know anything about View, and the idea is that a View can switch Controllers (for instance depending upon who has logged to the system) & a single controller can be used by multiple Views. View subscribes to the changes done to the model & hence both are sync from the data perspective. One of the disadvantages of MVC is that it’s difficult to unit test. Controller manipulates the data but how about asserting those changes from a view perspective. For instance on click of a button you raise an event to controller, and controller modifies the value in model. This value modification changes the font size / color in View. Unit testing this scenario is slightly difficult in MVC.

MVP: Again three components. But dependencies change (look at arrows in the diagram). Over here we replace Controller with Presenter (one which presents the changes done in model back to view). The main difference between both is that Presenter refers back to the view while Controller doesn’t. Normal pattern found here is to create an abstraction of the View (in terms of properties / events) & Presenter refers to it. This makes the mocking of View much easier & hence the Unit Testing aspect. Presenter here hence takes the responsibility of not only manipulating model but also updating the view. Of course the implementations of MVP differ in real world in terms of how much thin the view is, some prefer keeping basic logic still inside view & taking complex logic in presenter, while others prefer keeping the entire logic in Presenter. Martin fowler describes 2 variations on MVP on these lines namely – Supervising Controller & Passive View described below
(A Passive View handles this by reducing the behavior of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view. This allows testing to be focused on the controller with little risk of problems in the view.
Supervising Controller uses a controller both to handle input response but also to manipulate the view to handle more complex view logic. It leaves simple view behavior to the declarative system, intervening only when effects are needed that are beyond what can be achieved declaratively.)

MVVM: Model–View-ViewModel talks of creating a new model (in addition to your domain model). This model normally adds additonal properties from the prespective of View (as we understand that View has controls in addition to data which it’s displaying). For instance if View had a property IsChecked and Presenter was setting in classic MVP, in MVVM Presenter will have that IsChecked Property which View will sync up with (doesn’t it look like Strategy pattern has been replaced with Observer?). So now a Presenter becomes more like a combo of – View Properties & Model properties which would be synchronized with View. So why not rename Presenter to ViewModel? Do that and you get MVVM. MVVM is attractive for platforms which support bi-directional binding with less effort.