[e_i_pi]

Doh, missed a zero. I did try 10000 repititions

[4D1]

Excellent topic, but I am more confused having read this than before... I don't even know what I am confused about, I have seen so many contradictory explanations in tutorials that I am not sure what to base my understanding on?!?!

As I understand MVC (Or as the case may be, do NOT understand) in the simplest possible form, and without using terminology like 'business logic' as a placeholder for a dissertation explanation of what it actually is(Which is probably what is required):

Controllers - are essentially the link between raw data and presentation? I usually see in tuts/examples a Controller representing a page, getting data from a model and passing it to the view.

Models - are responsible for CRUD raw data? I usually see in tuts/examples Models representing a single DB table.

Views - are responsible for presenting raw data? I usually see in tuts/examples Views just echoing data alongside HTML.

According to a number of responses here and some tutorial explanations, a view should be able to communicate with a model as well. While I sometimes think I understand I often come across a scenario where I don't know how/can't decide how to implement this architecture.

For instance, if both a Controller and a View can access a Model, and a controller can pass data to a view, when should the controller pass data and when should the view get it itself?

If a model is responsible solely for retrieving raw data, where should organizational stuff take place, for instance organizing categories (parent->subcategories)?

If some information is represented across multiple tables, should a Model represent this relationship or should there be individual Models used in conjunction with one another?

What about all the other elements of a web application, like Cookies, Sessions, Get, Post etc... There never seems to be an explanation of where these fit into this architecture, should they be wrapped in helper classes and used in the controller? If I want to have data about a customer stored in a Session, should I use a Session wrapper class or create a Customer class that uses a Session wrapper class internally, or just deal with the Session array raw in a controller? Similarly if I wanted to make a shopping cart, would I create a shopping cart class which uses session/cookie helper classes internally?

This post has been edited by 4D1: 30 March 2012 - 06:45 AM

[CTphpnwb]

4D1, on 30 March 2012 - 09:38 AM, said:

As I understand MVC (Or as the case may be, do NOT understand) in the simplest possible form, and without using terminology like 'business logic' as a placeholder for a dissertation explanation of what it actually is(Which is probably what is required):

Business logic is the part of the code that makes decisions. It has loops, function/method calls, if and/or switch statements, etc. It's what makes the site dynamic. HTML for example, is static, not dynamic, so it doesn't belong with the business logic.

4D1, on 30 March 2012 - 09:38 AM, said:

Controllers - are essentially the link between raw data and presentation? I usually see in tuts/examples a Controller representing a page, getting data from a model and passing it to the view.

Yes.

4D1, on 30 March 2012 - 09:38 AM, said:

Models - are responsible for CRUD raw data? I usually see in tuts/examples Models representing a single DB table.

Models are responsible for all database access. Tutorials need to be simple to get their point across. A model can access more than one table and even more than one database.

4D1, on 30 March 2012 - 09:38 AM, said:

Views - are responsible for presenting raw data? I usually see in tuts/examples Views just echoing data alongside HTML.

Views are responsible for generating the HTML the browser receives. The browser is responsible for representing/rendering it.

4D1, on 30 March 2012 - 09:38 AM, said:

According to a number of responses here and some tutorial explanations, a view should be able to communicate with a model as well. While I sometimes think I understand I often come across a scenario where I don't know how/can't decide how to implement this architecture.

A view should communicate with the model through the controller.

4D1, on 30 March 2012 - 09:38 AM, said:

For instance, if both a Controller and a View can access a Model, and a controller can pass data to a view, when should the controller pass data and when should the view get it itself?

Ideally, the view is the last thing called. The controller gets the data from the model and then calls the view.

4D1, on 30 March 2012 - 09:38 AM, said:

If a model is responsible solely for retrieving raw data, where should organizational stuff take place, for instance organizing categories (parent->subcategories)?

That depends on what you're doing, right? If you're looking for information on data then it will take place in the model. If you're displaying that information it will take place in the view.

4D1, on 30 March 2012 - 09:38 AM, said:

If some information is represented across multiple tables, should a Model represent this relationship or should there be individual Models used in conjunction with one another?

One model can handle it, but I don't believe that's a requirement.

4D1, on 30 March 2012 - 09:38 AM, said:

What about all the other elements of a web application, like Cookies, Sessions, Get, Post etc... There never seems to be an explanation of where these fit into this architecture, should they be wrapped in helper classes and used in the controller? If I want to have data about a customer stored in a Session, should I use a Session wrapper class or create a Customer class that uses a Session wrapper class internally, or just deal with the Session array raw in a controller? Similarly if I wanted to make a shopping cart, would I create a shopping cart class which uses session/cookie helper classes internally?

The controller controls, so it should start sessions, get cookies, etc.

If you have a shopping cart class you could store the whole thing in one session variable as long as you load the class before starting the session.

[4D1]

CTphpnwb, thanks for being so thorough...

Would you mind just clarifying some other issues regarding MVC?

Quote

That depends on what you're doing, right? If you're looking for information on data then it will take place in the model. If you're displaying that information it will take place in the view.

I was refering to an application I built in an MVC-esque style, I had a table for categories, which is a self referencing table, when I pulled the data I sorted it into a parent child assoc array, so I could just echo it out in the view with a simple loop, I did the sorting in the model is that correct?

Quote

A view should communicate with the model through the controller.

In what context? should the view request what it needs itself by calling a controller method, or be passed what it needs by the controller?

Quote

Ideally, the view is the last thing called. The controller gets the data from the model and then calls the view.

Should a view be a class then? Or can it just be HTML with simple PHP statements that can be loaded or included?

This post has been edited by 4D1: 03 April 2012 - 05:01 PM

[CTphpnwb]

• A database will be faster at sorting than PHP, and it's easier to just write a query.
  
• The controller does the calling, not the view so the controller should be passing everything the view needs to it.
  
• I try to avoid using PHP and HTML in the same file. It just adds confusion by eliminating structure. The goal of MVC is to add structure so that when you need to make a change you know right where to start.

[Atli]

CTphpnwb, on 04 April 2012 - 01:22 AM, said:

The controller does the calling, not the view so the controller should be passing everything the view needs to it.

That's not exactly right though. Like I described in post #4, that's not how the MVC pattern works, but rather how a three-tier application works. In a MVC application, the view will get data from the model without having to go through the controller. The controller is just responsible for making changes to the model and then triggering the correct view.

[e_i_pi]

Just to clarify/add to some of the points CTphpnwb has made here:

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

Controllers - are essentially the link between raw data and presentation? I usually see in tuts/examples a Controller representing a page, getting data from a model and passing it to the view.

Yes.

Controllers need not represent a page, they could represent simply a component of a page, or even a process. Ultimately, a page will be generated by a Controller, but that Controller may in turn reference multiple other Controllers, coordinating and reacting to their I/O.

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

Models - are responsible for CRUD raw data? I usually see in tuts/examples Models representing a single DB table.

Models are responsible for all database access. Tutorials need to be simple to get their point across. A model can access more than one table and even more than one database.

Models can (and shuld) also be responsible for establishing a connection to the DB. The Model layer can be equally termd the Data layer.

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

Views - are responsible for presenting raw data? I usually see in tuts/examples Views just echoing data alongside HTML.

Views are responsible for generating the HTML the browser receives. The browser is responsible for representing/rendering it.

Views can also be code-free templates that are consumed by Controllers during the HTML generation process. The Controller can corral the View templates and the Model data, combining them using "business logic", eventually comminucating the output back to the user/browser.

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

According to a number of responses here and some tutorial explanations, a view should be able to communicate with a model as well. While I sometimes think I understand I often come across a scenario where I don't know how/can't decide how to implement this architecture.

A view should communicate with the model through the controller.

This is where the term MVC becomes problematic. In an MVC framework, the View can comminuate directly with the Model. In a 3-tier application (Data layer, Logic layer, Presentation layer), the View (i.e. - Presentation layer) communicates only with the Controller (i.e. - Logic layer). I use the terms MVC and 3-tier interchangeably, but this is a mistake. It is like referring to all pre-20thC music as "Classical", when Classical was in fact simply an era between the Baroque and Romantic eras.

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

If a model is responsible solely for retrieving raw data, where should organizational stuff take place, for instance organizing categories (parent->subcategories)?

That depends on what you're doing, right? If you're looking for information on data then it will take place in the model. If you're displaying that information it will take place in the view.

As CT has said in another post, it is generally best to leave the organising of data structure up to the SQL server, as that is what it's designed to do. Sometimes though we need to organise data within the PHP server. This can be done by either the Model or the Controller. In practice, I let the Model determine the structure of the data (e.g. - associative array), and the Controller format the data (e.g. - casting from int to string).

CTphpnwb, on 04 April 2012 - 02:50 AM, said:

4D1, on 30 March 2012 - 09:38 AM, said:

If some information is represented across multiple tables, should a Model represent this relationship or should there be individual Models used in conjunction with one another?

One model can handle it, but I don't believe that's a requirement.

There are multiple ways to approach the problem, some good some bad. I won't argue either way, but a pattern that I follow is to have a Model deal with a meta-concern. For instance, if I have a User class (Controller), I will also have a User model to accompany it. I may make an AdminUser class that extends off the User class, yet retain the User model as the primary Model for the AdminUser class. I may extend a Controller without extending the associated Model, or vice versa - it all depends on the needs of that part of the application.

This post has been edited by e_i_pi: 03 April 2012 - 07:03 PM

[4D1]

Thanks for clearing some things up guys, although my application is more a 3 tier application than strictly MVC it does exactly what I want, I believe everything is in a logical order and it is easy to know where code responsibilities are, while I'm not disputing the benefits of strict MVC, I think I will wait for a special case to implement a strict version of it. 3 Tier is sufficient for my needs at present.

[JackOfAllTrades]

This seems like a good topic to scream:

ARRRRGGGGHHHHH!!! My boss's view code is making me want to stab my eyes out with a rusty fork! CTphpnwb would have a friggin' stroke!