MVC, Business Logic, and other things that hurt my brain

  • (2 Pages)
  • +
  • 1
  • 2

23 Replies - 20540 Views - Last Post: 30 May 2012 - 06:45 AM Rate Topic: -----

#16 e_i_pi  Icon User is offline

  • = -1
  • member icon

Reputation: 795
  • View blog
  • Posts: 1,681
  • Joined: 30-January 09

Re: MVC, Business Logic, and other things that hurt my brain

Posted 20 September 2011 - 02:38 PM

Doh, missed a zero. I did try 10000 repititions :)
Was This Post Helpful? 0
  • +
  • -

#17 4D1  Icon User is offline

  • D.I.C Head

Reputation: 22
  • View blog
  • Posts: 225
  • Joined: 22-October 09

Re: MVC, Business Logic, and other things that hurt my brain

Posted 30 March 2012 - 06:38 AM

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

Was This Post Helpful? 1
  • +
  • -

#18 CTphpnwb  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3001
  • View blog
  • Posts: 10,393
  • Joined: 08-August 08

Re: MVC, Business Logic, and other things that hurt my brain

Posted 03 April 2012 - 08:50 AM

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.

View Post4D1, 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.
Was This Post Helpful? 1
  • +
  • -

#19 4D1  Icon User is offline

  • D.I.C Head

Reputation: 22
  • View blog
  • Posts: 225
  • Joined: 22-October 09

Re: MVC, Business Logic, and other things that hurt my brain

Posted 03 April 2012 - 04:58 PM

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

Was This Post Helpful? 0
  • +
  • -

#20 CTphpnwb  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3001
  • View blog
  • Posts: 10,393
  • Joined: 08-August 08

Re: MVC, Business Logic, and other things that hurt my brain

Posted 03 April 2012 - 06:22 PM

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

Was This Post Helpful? 0
  • +
  • -

#21 Atli  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 3719
  • View blog
  • Posts: 5,991
  • Joined: 08-June 10

Re: MVC, Business Logic, and other things that hurt my brain

Posted 03 April 2012 - 06:48 PM

View PostCTphpnwb, 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.
Was This Post Helpful? 0
  • +
  • -

#22 e_i_pi  Icon User is offline

  • = -1
  • member icon

Reputation: 795
  • View blog
  • Posts: 1,681
  • Joined: 30-January 09

Re: MVC, Business Logic, and other things that hurt my brain

Posted 03 April 2012 - 07:01 PM

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

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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.

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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.

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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.

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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.

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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).

View PostCTphpnwb, on 04 April 2012 - 02:50 AM, said:

View Post4D1, 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

Was This Post Helpful? 1
  • +
  • -

#23 4D1  Icon User is offline

  • D.I.C Head

Reputation: 22
  • View blog
  • Posts: 225
  • Joined: 22-October 09

Re: MVC, Business Logic, and other things that hurt my brain

Posted 04 April 2012 - 02:18 AM

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.
Was This Post Helpful? 0
  • +
  • -

#24 JackOfAllTrades  Icon User is offline

  • Saucy!
  • member icon

Reputation: 6066
  • View blog
  • Posts: 23,526
  • Joined: 23-August 08

Re: MVC, Business Logic, and other things that hurt my brain

Posted 30 May 2012 - 06:45 AM

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!
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2