Free Software,Free Society

Friday 1 May 2015

MVC (model-view-controller )

No comments :





       MVC stands for model-view-controller and is a common design pattern used in many software development frameworks. The main benefits of using an MVC architecture are code reusability and separation of concerns. WordPress doesn't use an MVC architecture, but does in its own way encourage code reuse and separation of concerns.

I explain the MVC architecture very briefly and how it maps to a WordPress development process. This section should help readers who are familiar with MVC-based frameworks understand how to approach WordPress development in a similar way.
Figure 1-3 describes a typical MVC-based application. The end user uses a controller, which manipulates the application state and data via a model, which then updates a view that is shown to the user. For example, in a blog application, a user might be looking at the recent posts page (a view). The user would click a post title, which would take the user to a new URL (a controller) that would load the post data (in a model) and display the single post (a different view).
 How MVC works.




 How MVC works

The MVC architecture supports code reusability by allowing the models, views, and controllers to interact. For example, both the recent posts view and the single posts view might use the same post model when displaying post data. The same models might be used in the frontend to display posts and in the backend to edit them.
The MVC architecture supports separation of concerns by allowing designers to focus their attention on the views, while programmers focus their attention on the models.

You could try to use an MVC architecture within WordPress. There are a number of projects to help you do just that; however, we think trying to strap MVC onto WordPress could lead to issues unless the WordPress core were to officially support MVC. Instead, we suggest following the WordPress Way ,as outlined

Still, if you are interested
MVC plugins for WordPress





There are a couple of ways to map an MVC process to WordPress.

Models = plugins

In an MVC framework, the code that stores the underlying data structures and business logic are found in the models. This is where the programmers will spend the majority of their time.

In WordPress, plugins are the proper place to store new data structures, complex business logic, and custom post type definitions.

This comparison breaks down in a couple of ways. First, many plugins add view-like functionality and contain design elements. Take any plugin that adds a widget to be used in your pages. Second, forms and other design components used in the WordPress dashboard are generally handled in plugins as well.
One way to make the separation of concerns more clear when adding view-like components to your WordPress plugins is to create a “templates” or “pages” folder and put your front end code into it. Common practice is to allow templates to override the template used by the plugin. For example, when using WordPress with the Paid Memberships Pro plugin, you can place a folder called “paid-memberships-pro/pages into your active theme to override the default page templates.

Views = themes

In an MVC framework, the code to display data to the user is written in the views. This is where designers will spend the majority of their time.

In WordPress, themes are the proper place to store templating code and logic.

Again, the comparison here doesn't map one to one, but “views = themes is a good starting point.

Controllers = template loader

In an MVC framework, the code to process user input (in the form of URLs or $_GET or $_POST data) and decide which models and views to use to handle a request are stored in the controllers. Controller code is generally handled by a programmer and often set up once and forgotten about. The meat of the programming in an MVC application happens in the models and views.


In WordPress, all page requests (unless they are accessing a cached .html file) are processed through the index.php file and processed by WordPress according to the Template Hierarchy. The template loader figures out which file in the template should be used to display the page to the end user. For example, use search.php to show search results, single.php to show a single post, etc.
The default behavior can be further customized via the WP_Rewrite API) and other hooks and filters.

Codex information on the Template Hierarchy is available online; the Template Hierarchy is covered in more depth in Chapter 4.
For a better understanding of how MVC frameworks work, the PHP framework Yii has a great resource explaining how to best use their MVC architecture.

For a better understanding of how to develop web applications using WordPress as a framework  book.

No comments :

Post a Comment