In a new post to his site Paul Jones wonders out loud about why developers think MVC is an application architecture versus just a user interface pattern.

I’ve pointed out before that Model-View-Controller is a user interface pattern, not an application architecture. But why would PHP developers get the idea that MVC is an application architecture in the first place?

[...] I used to think that MVC was an application architecture. Even after reading Fowler’s POEAA and seeing that MVC was for the user interface, I figured that meant I was doing “user interface applications.” But that was not quite right; it would have been more accurate to say that I had been mixing the concerns of user interface with the underlying core application.

He suggests that the reason MVC is commonly thought of as an architecture is because of the "flow" most PHP developers follow in their learning and development practices. Starting from "page scripts" where things are all mashed together, a developer then learns about the separation of concerns and how MVC helps splitting up the application easier. Paul includes a reminder, though, that the "user interface" isn't really just the frontend parts (HTML, CSS, JS) but the HTTP request/response to and from the application.

In response to a recent post from Anthony Ferrara about MVC Paul Jones suggests that Anthony's view that it and related structures "all pretend to be application architectures" is false.

The central mistake I think Anthony makes is near the end of this post, where he states (in talking about MVC, ADR, et al.) that “All Pretend To Be Application Architectures.” That assertion strikes me as incorrect. While it may be that developers using MVC may mistakenly think of MVC as an application architecture, the pattern description itself makes no such claim. Indeed, Fowler categorizes MVC as a “Web Presentation Pattern” and not as an “Application Architecture” per se. [...] Fowler’s categorization and description of MVC define it pretty clearly as a user interface pattern. ADR, as a refinement of MVC, is likewise a user interface pattern.

He goes on to talk more about the ADR (Action-Domain-Responder) pattern, how it's more of a user interface pattern as well and how that relates to using it for HTTP requests. He suggests that the definition from Anthony may be a bit too broad and proposes the alternative "All Are User Interface Patterns, Not Entire Application Architectures" to be a bit more specific.

Following up on his previous article talking about the MVC design pattern (and the idea of "MVC"), Anthony Ferrara has posted some alternatives to MVC for your consideration. These other options are mostly variants of the typical MVC structure and could be considered "siblings".

Last week, I wrote A Beginner's Guide To MVC For The Web. In it, I described some of the problems with both the MVC pattern and the conceptual "MVC" that frameworks use. But what I didn't do is describe better ways. I didn't describe any of the alternatives. So let's do that. Let's talk about some of the alternatives to MVC...

He starts by restating some of the major issues with the typical MVC implementation (three of them). From there, he covers each of the alternatives with a summary paragraph or three about each:

• HMVC - Hierarchical Model-View-Controller
• MVVM - Model-View-ViewModel
• MVP - Model View Presenter
• MVA - Model View Adapter
• PAC - Presentation Abstraction Control
• RMR - Resource-Method-Representation
• ADR - Action-Domain-Responder

He talks about the similarities between them, mainly that they're all "triads" of functionality and that they all have the same basic purpose. He also suggests that they're all "pretending" to be application architectures.

If it's not clear where something fits in your application, that's a sign that your application architecture is flawed. Not that you need to introduce some magic in to get it to work. So let's admit that none of these are application architectures... And let's admit that there is a problem we need to solve.

Anthony Ferrara has posted what he calls a beginners guide to MVC for the web, a tutorial that introduces to you the basic concepts behind the Model-View-Controller design pattern and how it should fit in with the SOLID design principles.

There are a bunch of guides out there that claim to be a guide to MVC. It's almost like writing your own framework in that it's "one of those things" that everyone does. I realized that I never wrote my "beginners guide to MVC". So I've decided to do exactly that. Here's my "beginners guide to MVC for the web".

He starts with his first lesson, his most important one really - you don't need "MVC" (the concept, not the pattern...he notes them differently). He then gets into what the MVC pattern actually is and describes each piece and how they fit together. Following that, he talks about "MVC" as a concept and how it's different from MVC, the design pattern (hint: the pattern describes one implementation of the MVC ideals). He talks about the role of state in the MVC structure and how the implementation of the MVC idea is slightly different in the various "MVC frameworks" out there.

There is a very useful lesson that MVC brings: Separation Of Concerns. Meaning that you should separate different responsibilities into different sections of your application. Separation of Concerns is a necessary step in dealing with Abstraction. Instead of latching on to MVC, latch on to abstraction. Latch on to separation of concerns. Latch on to architecture. There are far better ways to architect and abstract user interaction for server-based applications than MVC.

If you're relatively new to the world of the MVC (Model-View-Controller) design pattern and its use, you may be trying to figure out exactly what each piece is. One of the more difficult relationships is between models and controllers, more specifically what each are supposed to contain. In this discussion over on Reddit several people weigh in on their opinions and own suggestions about what models should be.

Sometimes I feel I should avoid session in model ... but sometimes I feel using session in controller is putting business logic in controller which is bad ... sometimes I feel I should avoid $_POST and $_GET in model ... but sometimes I feel receiving data in controller and then send all of them to model is an unnecessary move ... sometimes I feel one model should represent almost everything about one certain table ... sometimes I feel it's almost god pattern if that table is the core of your application, but separate the model into many model is confusing too since they are using the same table. I wanna be a Model Master who can explain 'Model' very well. Who can help me plz.

Comments on the post explain models in several different ways including:

• Thinking of it as a representation of "domain" functionality
• Models as a 1-to-1 relationship with database tables
• The differences between them and collections
• Links to some helpful libraries like Eloquent and Doctrine

In his latest post Paul Jones has proposed a "tentative MVC refinement" as the structure behind your application. He suggests something called the action-domain-response pattern, focusing on some of the more common practices in web application development today instead of an ideal.

The term MVC has experienced some semantic diffusion from its original meaning, especially in a web context. Because of this diffusion, the Action-Domain-Response pattern description is intended as a web-specific refinement of the MVC pattern. I think ADR more closely fits what we actually do in web development on a daily basis. [...] We generally route and dispatch not to a controller class per se, but to a particular action method within a controller class. It is also partly revealed by the fact that we commonly think of the template as the View, when in a web context it may be more accurate to say that the HTTP response is the View. As such, I think ADR may represent a better separation of concerns than MVC does in a web context.

He goes through the structure he's worked up, showing the interaction between the parts and compares the flow to a typical MVC-based application. He also mentions a few other MVC pattern alternatives including Data-Context-Interaction and Model-View-ViewModel. He then gets into an actual code-based example using a typical blog application. He compares the directory structure and proposes that instead of one controller per file it becomes one action per file (and one response per file accordingly).

If you're relatively new to the framework world and haven't quite gotten your head around the whole Model/View/Controller way of doing things, you should check out this new tutorial from NETTUTS.com giving an overview of the method that's so popular among PHP frameworks these days.

Model-View-Controller (MVC) is probably one of the most quoted patterns in the web programming world in recent years. Anyone currently working in anything related to web application development will have heard or read the acronym hundreds of times. Today, we'’ll clarify what MVC means, and why it has become so popular.

The look at each part of the MVC stack including what it's for and how it connects with the other two parts. An example is included - not in code but with an image showing the communication between the modules. They wrap up the post with a look at why using a MVC framework can help you be more productive. Their example uses CakePHP but the ideas could be applied to any MVC framework out there.

DevShed takes another look at the CodeIgniter framework with this first part of a new series tackling view handling in the lightweight framework. Views are the final stop for the processed data, displaying any one of a multitude of types of data back out to the waiting client software.

In reality, implementing this view-centric method is actually pretty easy to achieve. However, CodeIgniter provides web developers with enough flexibility to handle views in all sort of clever ways. Therefore, in this series of articles I’ll be discussing in detail some common approaches that you can use to generate views, ranging from loading them sequentially, to using more complex methods, such as including views within other views.

They introduce you to the view system CodeIgniter offers and show you how to create a basic view as a part of a controller class that displays a page with a header, user content and a footer.

On the heels of some previous comments concerning the Smarty PHP templating engine, Quinton Parker has posted some of his own thoughts concerning the past and future of the tool.

Today's rant is about the Smarty templating system for PHP. A recent blog post by Paul M. Jones has rekindled my strong feelings against Smarty. Honestly its nothing personal. Its just I can’t believe developers are still using Smarty or that they ever started using it. Unthinkable.

Quinton talks about when he first discovered patterns and N-tier including the Model-View-Controller pattern. This naturally lead to needing a templating engine for the views, but from everything he could tell about Smarty it "solved the wrong problem" (he chose phpsavant instead). He even points out an author who, despite writing a book on Smarty, still came back and said that there's no need to use something like that in an application.

Jani Hartikainen has posted some food for thought to his blog today concerning models in a typical Model-View-Controller (MVC) setup.

"What is a model" and "Is Zend_Db_Table a model" seem to be asked once in a while on #zftalk. Frameworks say they have a full model available, thus they are MVC frameworks ORM libraries say they generate models. It seems the ActiveRecord pattern has become somewhat synonymous with model.

He points to a post from Padraic Brady on the subject and talks about how one might put it into practice. He admits to making a controller action just to get data from the database into a view, but offers a "more correct" alternative - a view helpers that creates a model instance your view scripts can use directly without the controller in between.