Page 1 of 1

MVC architecture.......

Posted: Tue Jun 30, 2009 4:45 am
by narsimha
what is mvc architecture in php ?
What are Frame Works in php ?

Re: MVC architecture.......

Posted: Tue Jun 30, 2009 5:04 am
by jayshields

Re: MVC architecture.......

Posted: Tue Jun 30, 2009 6:17 pm
by SeaJones
MVC = Model View Controller. Method of programming in many languages (originally ages ago in SmallTalk). MVC seperates out code that deals with the processing of data etc (model), the preparing of data for showing the user/interacting with the user (controller) and the user interface itself (view).

Put simply, if you wrote a php script that queried a database, parsed the results to make them readable, then the SQL query would be part of the models, the making readable would be the Controller and the page that showed them would be the view.

Frameworks are systems written to coordinate a language and deal with some fundamentals for the programmer. They often offer a range of tools such as inbuilt database functions, text parsers and so on, and frequently include system performance enhancing features like a caching engine. Many Frameworks (Zend, CI etc) are also based on the MVC idea, although a fair few aren't.

Re: MVC architecture.......

Posted: Tue Jun 30, 2009 8:23 pm
by volomike
Frameworks. PHP is actually fairly basic when you want to make a full-blown app. A framework allows you to get to your destination faster, but has a learning curve, and there seems to be a new PHP framework arriving on the scene every 6 months. Hopefully eventually that will settle down. Right now the top MVC frameworks are in discussions about standards and interoperability, rumor has it.

MVC. Let's invert the acronym a little better to what you might be used to -- although it's formally called MVC, and should always be referred to as MVC, let's think of it as CMV for a moment because that's how work gets routed in it.

controller = two parts, Front and Page controllers. The Front Controller takes the incoming request, the click, the form post, etc., and analyzes the URL and perhaps the data inside the form post (sometimes) to determine where to route the request. It's like a telephone directory where incoming input gets assigned to a single page controller of many page controllers. A Page Controller receives the request from the Front Controller and handles input and the glue among the models and the views.

models = Basically this is the "meat" of your website or web application. However, it can be done a variety of ways. Let's consider the Domain Object way because it's often the most common.

In the Domain Object way, split up your major concepts of your site and call those things as Domain Objects. So, you build classes for things like Users, Employers, Widgets, Orders, Payments, Inventory, etc. Then, you build what is called CRUD on those classes. That stands for class methods on that class to permit you to do Create, Read, Update, and Delete. Now, don't take that literally -- there might be specific things you want to update about a domain object. For instance, I may want something like 4 specific class methods for something I want to update.

Now you can create Sub Objects (perhaps there's another name for this) to the Domain Objects by realizing the minor concepts of your site and building CRUD classes for them.

views = These are the page templates and/or your presentation layer of output. If you have a command-line program, for instance, then it would handle the formatting of that result on the screen, such as using VT100 style codes. If you have a web-based program, then it would handle the formatting as XHTML/CSS and Javascript. If doing a web service, then you might be interacting with XML or JSON or other format. Anyway, the page controllers pull data from the models and send it to the views to be presented to the end user.

Some people might call a view a "template".

So, it's like this:

(data input) --> front controller --> (page controller <--> model, page controller --> view) --> (data output)

The reason MVC is used is because it makes more intuitive code logic and less spaghetti code (potentially, if done properly). You end up separating request routing; field validation, cleaning, processing; database (or other medium) input/output; and output formatting.

So, and every framework does this differently, but often you see all these OOP classes divided up into folders like this:

controllers (or _controllers)
models (or _models)
views (or _views)
system (or _system or _library or library)

The system folder (no matter what it is called in each framework) is the library that drives the whole framework so that stuff moves through controllers, models, and views properly and comes with lots of other goodies to make your life easier, such as a way to do breadcrumbs, manage dates, login/authenticate a user, etc.

Hope this helps.

Re: MVC architecture.......

Posted: Tue Jun 30, 2009 10:29 pm
by Christopher
I think it makes more sense to think about MVC in what problems it solves and how it solves them. If you start with a normal PHP script then you have everything in one piece of code. That is called a Transaction Script. The code may check the Request for the existence of certain values that specify a behavior or get values that are input from the user. Then you may apply some checks or transformations to the values, and you may load or save values from/to a datasource. Finally you would create a Response to send back to the user. That code is usually all mixed together in traditional PHP scripts. And because it is all mixed together there is no reusablity and it can be difficult to maintain. So you want to start pulling code out in reusable, maintainable modules.

The first and most important thing to separate out is what is often called the Business Logic. It is the part of the code that manages the applications persistent data, plus the application logic related to dealing with that data. This part of the code deals with what is called the Domain. When you create a software representation of the Domain it is called the Domain Model. In MVC it is just called the Model. Typically it is one or more separate classes that provide access to the core data and logic of the application. It is also important to remember that the Domain is a separate layer below the other code in the script, so the Model should not have any dependencies on the rest of the code.

The second thing to separate out is the code that generates the Response back to the user. Typically that Response it a formatted version of data from one or more Models. This is sometimes called presentation code, in MVC it is called the View. The nice thing about separating out this presentation code is that you may have different Responses that use the same data -- for example HTML, XML, JSON or RSS. Also in this code any display logic that might determine when and how things are displayed. And any kind of templating is done in this View code.

So if you have separated out the Domain Model and the Presentation View then what is left is some Request processing and the code that controls program flow based on values from the Request/Model/View. That leftover code is the Controller. In a Transaction script it is often the first thing you write, but in MVC you can see that it should be the last because it needs existing Models and View to control.

The interesting thing about this MVC solution is that buried in what I described above are a bunch of good practices. One of the main reasons why MVC is so popular is because within its design it has these good practices as intended side effects.


A application framework is any code that is reusable in multiple, different applications. A MVC framework is a framework that is designed to support and encourage the MVC separations.

Re: MVC architecture.......

Posted: Wed Jul 01, 2009 5:10 am
by SeaJones
I think it's important to clarify one thing about the 'View' element of MVC.

Views is just what is seen, but that's not to say that a view page is a codeless Markup page with the odd inserted <?=$variable ?> tag, it's more than that and importantly so.

The view deals with processed data and presents it to the user, so whilst it may well be an (X)HTML or other SGML based language page peppered with echoed variables, it may also contain code for processing arrays (a foreach, for example) or loops for alternately applying different stylings to table rows, that kind of thing.

Depending on how you view the concept, a view may be use to generate RSS feeds too, thus basically creating raw data of it's own. I know devs who would use a view for this and some who would use a controller (when you refer to a view producing 'raw data' as I did, it suddenly seems very wrong to use a view to generate RSS...

Re: MVC architecture.......

Posted: Wed Jul 01, 2009 9:45 am
by volomike
SeaJones wrote:it may also contain code for processing arrays (a foreach, for example) or loops for alternately applying different stylings to table rows, that kind of thing.
Good point.

Re: MVC architecture.......

Posted: Wed Jul 01, 2009 3:04 pm
by BornForCode
After you read all smart ideas above you should remember that MVC like some other application architecture patterns is all about loosely coupled architecture.

Imagine the MVC like a sandwich, you put some bred (that is the base, foundation, in our case data, alias models) but you should add something because just bread is not good so you add some meat (controlling or where things happen) but if you look at the sandwich looks like hell so you add something that simply may add some taste but makes him to look better so you add some ketchup etc (that is the view).

Now if you want to change the meat there is not problem since you can put pork, cow etc. But for example if you don't like ketchup you can always change it and put some cheese, pepperoni etc. You will always have your sandwich there ready to be eaten (loosely coupled architecture).

Was my example helpful? :mrgreen:

Re: MVC architecture.......

Posted: Thu Jul 02, 2009 4:35 am
by SeaJones
I dunno mate, I've never had to scrape any ketchup off a controller when making changes... ;)

Re: MVC architecture.......

Posted: Fri Jul 03, 2009 6:47 pm
by volomike
BornForCode - I need to hire you for all my sales calls. LOL

Re: MVC architecture.......

Posted: Fri Jul 03, 2009 7:16 pm
by Christopher
BornForCode wrote:Imagine the MVC like a sandwich, you put some bred (that is the base, foundation, in our case data, alias models) but you should add something because just bread is not good so you add some meat (controlling or where things happen) but if you look at the sandwich looks like hell so you add something that simply may add some taste but makes him to look better so you add some ketchup etc (that is the view).

Now if you want to change the meat there is not problem since you can put pork, cow etc. But for example if you don't like ketchup you can always change it and put some cheese, pepperoni etc. You will always have your sandwich there ready to be eaten (loosely coupled architecture).
I think this analogy is incorrect! ;) When you order a sandwich you order by the meat so that would be the Domain. Since the bread holds everything together it would be the Controller. That means the View would be cheese and condiments. So when you order a sandwich you say, "I would like a Model on Controller with View."

Re: MVC architecture.......

Posted: Fri Jul 03, 2009 7:22 pm
by Eran
I would like a Model on Controller with View
nice! :)
put that in your signature