PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 31 Mar 2015 13:09:23 -050030http://www.phpdeveloper.org/news/22281http://www.phpdeveloper.org/news/22281
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.

Link: http://paul-m-jones.com/archives/6079]]>Mon, 26 Jan 2015 11:51:26 -0600http://www.phpdeveloper.org/news/22016http://www.phpdeveloper.org/news/22016
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:

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.

Link: http://blog.ircmaxell.com/2014/11/alternatives-to-mvc.html]]>Tue, 25 Nov 2014 11:52:15 -0600http://www.phpdeveloper.org/news/22008http://www.phpdeveloper.org/news/22008
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.

Link: http://blog.ircmaxell.com/2014/11/a-beginners-guide-to-mvc-for-web.html]]>Mon, 24 Nov 2014 10:42:41 -0600http://www.phpdeveloper.org/news/21331http://www.phpdeveloper.org/news/21331
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:

Link: http://www.reddit.com/r/PHP/comments/28luto/what_exactly_is_model_in_mvc/]]>Fri, 20 Jun 2014 11:25:48 -0500http://www.phpdeveloper.org/news/21140http://www.phpdeveloper.org/news/21140
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).

Link: http://paul-m-jones.com/archives/5970]]>Wed, 07 May 2014 09:49:36 -0500http://www.phpdeveloper.org/news/14246http://www.phpdeveloper.org/news/14246
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.

]]>Thu, 25 Mar 2010 10:05:34 -0500http://www.phpdeveloper.org/news/12171http://www.phpdeveloper.org/news/12171
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.

]]>Thu, 19 Mar 2009 12:04:42 -0500http://www.phpdeveloper.org/news/11901http://www.phpdeveloper.org/news/11901
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.

"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.

]]>Mon, 08 Dec 2008 10:26:15 -0600http://www.phpdeveloper.org/news/11505http://www.phpdeveloper.org/news/11505
In this new post to his blog Padraic Brady looks at why models are "misunderstood and unappreciated" in a Model/View/Controller sort of world.

By the time I'd finished both chapters [of my Zend Framework book] I realised I had spent a lot of space explaining the Model, most of it discussing how the Zend Framework does not actually give you one. In fact, no web application framework offers a complete Model (for reasons I'll explain later). However nearly all frameworks manage to avoid making that perfectly obvious. Instead they continually link the concept of a Model to the related, but not identical, concept of data access. This is quite misleading.

He looks at two things models are good for (maintaining state and enforcing rules on the data in the current state), how it seems most PHP developers perceive them, how controllers can be turned into "mutated models" and the idea that models should be classes and controllers are just processes (handlers for requests).