Have I got MVC all wrong?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Have I got MVC all wrong?

Post by Ambush Commander »

My touchdown with MVC came from Fowler's Patterns of Enterprise Application Architecture. He boiled it down to these:

1. Model -- Business logic
2. View -- User interface
3. Controller -- Mediates between changes in the interface and the model (not as important, although with the rise of AJAX it may be)

So I was studying CakePHP, evaluating it on whether or not I'd like to use it, and noticed that they touted MVC as their architecture. For them, it boils down to:

1. Model -- Database access
2. View -- User interface
3. Controller -- Business logic

Ehh? Am I going crazy or does CakePHP have the naming all wrong? I understand that in the first trio database access is kind of missing, so I'd suppose I'd put with the model, but CakePHP seems to have taken the normally useless controller and given it a totally new meaning, which is a mix between an Application Controller and a bunch of Transaction Scripts.

Hrmm...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Have I got MVC all wrong?

Post by alex.barylski »

Ambush Commander wrote:My touchdown with MVC came from Fowler's Patterns of Enterprise Application Architecture. He boiled it down to these:

1. Model -- Business logic
2. View -- User interface
3. Controller -- Mediates between changes in the interface and the model (not as important, although with the rise of AJAX it may be)

So I was studying CakePHP, evaluating it on whether or not I'd like to use it, and noticed that they touted MVC as their architecture. For them, it boils down to:

1. Model -- Database access
2. View -- User interface
3. Controller -- Business logic

Ehh? Am I going crazy or does CakePHP have the naming all wrong? I understand that in the first trio database access is kind of missing, so I'd suppose I'd put with the model, but CakePHP seems to have taken the normally useless controller and given it a totally new meaning, which is a mix between an Application Controller and a bunch of Transaction Scripts.

Hrmm...
I haven't read anything of Cake, but it's similar to Ruby?

Anyways, not that it's important, but...I wouldn't say a controller is typically useless, just not as obvious. Most programmers learn over time to modularize their code and seperate logical sections...business logic and view are easy to split in PHP/HTML via a template engine, but a controller is trickier to discover. I went years without using a formal MVC design, but for the most part had it bang on.

Secondly, if thats how Cake defines it's use of MVC, so be it I guess. They are just patterns, not actual blueprints afterall :P I feel a flame war coming on

I have read few articles which suggest an MVCA instead of the triad MVC, where A is the DB access layer. Perhaps Cake is of the same mindset?

The controller IMHO could interact with the model/business logic, but if the model is entirely handled by the DB, then business logic is fairly simple and could possibly be thrown into the controller???

I think this really depends on your implementation...

For instance:
1) User clicks a link
2) Controller fired up and determines which view to pull
3) Controller knows what view, now it must pull on model
4) Model called to insert user account (data, etc filtered by model)
5) Controller checks the return value of Model::insertUser and possibly creates another, etc
6) Controller updates model (if nessecary - if not GOTO 3)
7) Controller pull on model and retreives list of users
8) Passes the user array to the view for rendering

In this case, there is a bit of business logic intertwined with model and view.

Business logic just changes slightly...in a strict MVC paradigm the controller would possibly be ONLY responsible for connecting the Model and View and manipulating/showing each as requested by end user.

MVCA further abstracts things, in the sense that business logic and core model code are more tightly integrated...

Now instead of just calling a SQL: INSERT INTO so and so, the model also performs some data sanitization checks, etc...

Now you need to ask yourself, does the controller handle checking for duplicates via the model API or does the model handle checking for duplicates???

Personally I would side on the Controller checks for duplicates, because keeping functions atomic is likely the most important design decision one can make and yields far greater reusability.

By having the controller check for duplicates however, you have now introduced some business logic into a controller...

See what I'm saying?

Cheers :)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

You're correct: "subtle" is a more accurate way to portray the controller.

The reason why I am so disturbed by CakePHP's version of MVC is that the whole point about patterns is the power of a name: in theory, when a controller mentions a "Model" everyone should know what they're talking about. So I am (hopefully understandably) somewhat wary when a name is misleading. For me, the answer to "What's in a name" is "A lot." It's not the actual paradigm I'm worried about.
Personally I would side on the Controller checks for duplicates, because keeping functions atomic is likely the most important design decision one can make and yields far greater reusability.

By having the controller check for duplicates however, you have now introduced some business logic into a controller...

See what I'm saying?
Perhaps that's more validation/filtering logic, which does belong to the controller.

I'm being overly pendantic hmm... I suppose my biggest objection is that they're calling their database access Model.
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

Cake PHP does has "Scaffolding" -- HTML fields are mapped by name to corresponding database names. No need for configuration. That might explain the tighter MVC pattern. I just visited the site a bit yesterday. Great documentation. And yeah it's like Ruby on Rails -- claims to be a "rapid development" framework. Looks interesting I'm thinking about giving it a spin in the near future. When all the other projects I've got get done.... Yeah right :D
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Ambush Commander wrote:You're correct: "subtle" is a more accurate way to portray the controller.

The reason why I am so disturbed by CakePHP's version of MVC is that the whole point about patterns is the power of a name: in theory, when a controller mentions a "Model" everyone should know what they're talking about. So I am (hopefully understandably) somewhat wary when a name is misleading. For me, the answer to "What's in a name" is "A lot." It's not the actual paradigm I'm worried about.
Personally I would side on the Controller checks for duplicates, because keeping functions atomic is likely the most important design decision one can make and yields far greater reusability.

By having the controller check for duplicates however, you have now introduced some business logic into a controller...

See what I'm saying?
Perhaps that's more validation/filtering logic, which does belong to the controller.

Really depends on your design I think. For instance, if controller is responsible for the filter/data sanitization, then internal commands can be sped up (assuming internal commands don't use external data) as a direct call to the model doesn't incur performance hits of sanitizing. However, on the flip side, I personally consider the controller to be an integral part of it's model and it's view. With this in mind if you later had another section which required the same model functions, but different view, you couldn't expect *this* controller to just use the model directly *this* controller would now have to sanitize data. Depending on design and how tightly your MVC components are integrated - reusing the *other* controller might not make sense, but if you don't reuse it you've just introduced duplication into your source tree.

That's my reasoning anyways, but again it' depends on design and implementation of you MVC. I would personally feel uncomfortable using another MVC unit controller to avoid duplication.


I'm being overly pendantic hmm... I suppose my biggest objection is that they're calling their database access Model.

Naw...no such thing IMHO. Being anal only gets you deeper into the subject (no pun intended :P) which translates into a better understanding.
Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Have I got MVC all wrong?

Post by Christopher »

I don't think you have Fowler right. I don't think your description of Cake is right from my experience of the code, but if that is their naming the it is wrong. The thing about patterns like MVC is that they are solutions that sit on top of other solutions. The biggest problem with understanding MVC is that it involves two separations, and to make it even more confusing one of those is a layer separation. Most of these architecures are a spin on Two Tier or Three Tier.

Code: Select all

TWO TIER                             THREE TIER
Presentation Layer                    Presentation Layer
                                              |
        |                                     V
        V                               Domain Layer
                                              |
                                              V
    Data Layer                         Datasource Layer
To make it harder to understand, MVC does not specify that you use Two or Three Tier. So your Model may be the whole Data Layer, or it might be the Domain Layer with the Datasource Layer a dependency of the Model.

The VIew and the Controller are both in the Presentation Layer and have dependencies either strict or loose dependencies:

Code: Select all

Controller -> View           or             Controller <-> View
The other confusing thing is that where something occurs within the code does not necessarily tell you anything about the dependencies -- and they are what is important. So for example, the Datasource (usually a database connnection) is often instantiated in the Controller and then passed to the Model. That is not confusing MVC because the dependencies are all still correct -- the Datasource only know about itself, the Model know about the Datasource, and the Controller know about both. Remember, MVC does not necessarily say anything about the Datasource, but usually only know how to instantiate it and give it to the Model. Of course in Two Tier they are combined so it does not matter.

Finally no matter what anyone says, the dividing line between the View and the Controller is flexible. It really depends on the situation, but keeping to the strict dependency is the safe path. Probably the important thing is that they are performing their designated functions -- the View dealing with the display and the Controller managing program flow. A lot of the design of this is from the Java guys who did all the work on web application architectures. Anyway, here is my cut at MVC:

1. Model -- Domain logic that makes Datasources useful
2. View -- Display logic creates the Response
3. Controller -- Program Flow logic that undertands and manages the Request

I think the Controller is the most fun to program because it has all the dependencies -- but that makes it very easy to get it wrong. I don't know if you can ever get the Controller right.
(#10850)
User avatar
wtf
Forum Contributor
Posts: 331
Joined: Thu Nov 03, 2005 5:27 pm

Post by wtf »

Cake is great!!! I'll leave it at this.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Re: Have I got MVC all wrong?

Post by alvinphp »

Ambush Commander wrote: 1. Model -- Database access
2. View -- User interface
3. Controller -- Business logic
I would consider this wrong. I think of it this way, MVC spawned from Input, Processing, Output which would map out like this...

Controller = Input (this handles the requests that come in)
Model = Processing (is your business logic, which includes database access methods)
View = Output (is your user interface)

This is in the most simplist terms. And to further complicate matters the output can create javascript/ajax which could have its own MVC pattern. Or the database you call can have its own architecture using parts of MVC.
Last edited by alvinphp on Mon Sep 25, 2006 10:42 pm, edited 1 time in total.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Have I got MVC all wrong?

Post by alex.barylski »

alvinphp wrote:
Ambush Commander wrote: 1. Model -- Database access
2. View -- User interface
3. Controller -- Business logic
MVC spawned from Input, Processing, Output

Controller = Input (so it usually handles the requests that come in)
Model = Processing (is all your business logic, which includes the database access)
View = Output (is your dhtml (user interface))
Although I won't argue that MVC likely *evolved* (not sure about spawned) from IPO, they are from a paradigm perspective, quite different. IPO for instance is procedural in nature, in that it applies to console style applications.

It executes and terminates.

MVC is better suited (IMHO) for event driven architectures, where the entry point is clearly defined (controller) but whether any processing occurs is dependant on actions/events from the end user.

Just throwing in my 2 cents :roll:
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Have I got MVC all wrong?

Post by Christopher »

alvinphp wrote:I would consider this wrong. I think of it this way, MVC spawned from Input, Processing, Output which would map out like this...
I agree and I think I arrived at an almost identical list from the other direction.
alvinphp wrote:And to further complicate matters the output can create javascript/ajax which could have its own MVC pattern. Or the database you call can have its own architecture using parts of MVC.
That's the challenge and the fun part! ;)
(#10850)
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Re: Have I got MVC all wrong?

Post by alvinphp »

Hockey wrote:
alvinphp wrote:
Ambush Commander wrote: 1. Model -- Database access
2. View -- User interface
3. Controller -- Business logic
MVC spawned from Input, Processing, Output

Controller = Input (so it usually handles the requests that come in)
Model = Processing (is all your business logic, which includes the database access)
View = Output (is your dhtml (user interface))
Although I won't argue that MVC likely *evolved* (not sure about spawned) from IPO, they are from a paradigm perspective, quite different. IPO for instance is procedural in nature, in that it applies to console style applications.

It executes and terminates.

MVC is better suited (IMHO) for event driven architectures, where the entry point is clearly defined (controller) but whether any processing occurs is dependant on actions/events from the end user.

Just throwing in my 2 cents :roll:
MVC is also procedural in nature as the request comes in, it is processed, and then you output your results. You can use OOP with MVC.

IMHO, IPO and MVC is essentially the same thing where the names were changed just to better reflect IPO in the programming environment.
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Re: Have I got MVC all wrong?

Post by Buddha443556 »

arborint wrote:I don't think you have Fowler right.
I sometimes wonder if Fowler even got Reenskaug right.
The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer.
We spend a lot of time talking of the digital model and just about no time speaking of the mental model. :?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

arborint wrote:1. Model -- Domain logic that makes Datasources useful
2. View -- Display logic creates the Response
3. Controller -- Program Flow logic that undertands and manages the Request
About sums up my own understanding. I know there a lot of fluidity in the different approaches out there, but the above just seems more intuitive.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Have I got MVC all wrong?

Post by Christopher »

Buddha443556 wrote:I sometimes wonder if Fowler even got Reenskaug right.
Actually, I think Fowler is one of the few who gets it right because he emphasizes the layers and two separations. Most others just slap up a diagram with dependency arrows like a triangle and ultimately confuse the hell out of people.
Buddha443556 wrote:We spend a lot of time talking of the digital model and just about no time speaking of the mental model. :?
If you read the whole quote it is about enabling the user to have the illusion of manipulating the domain. So more important to programmers would be to clarify the domain -- which is a major thrust in modern design thinking.
(#10850)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

I'm no expert but I have:

1. View consisting of a "View" class and a template file
2. Model -- access to data with get/set/mutate methods
3. Controller - Deal with user activity, invoke changes in model, provide updated model for View

Code: Select all

class Model
{
    private $someData = 'default';
    
    public function setSomeData($data)
    {
        $this->someData = $data;
    }

    public function getSomeData()
    {
        return $this->someData;
    }
}

class Controller
{
    private $model;
    
    public function setModel($model)
    {
        $this->model = $model;
    }

    public function getModel()
    {
        return $this->model;
    }
    
    public function execute()
    {
        if (!empty($_POST['user_input'])) $this->model->setSomeData($_POST['user_input']);
    }
}

class View
{
    private $model;
    
    public function setModel($model)
    {
        $this->model = $model;
    }
    
    public function paintTitle()
    {
        echo 'Some title from somewhere';
    }

    public function paintSomeData()
    {
        echo $this->model->getSomeData();
    }

    public function render()
    {
        include 'some_template_file.php';
    }
}

$controller = new Controller();
$controller->setModel(new Model());

$controller->execute();

$view = new View();
$view->setModel($controller->getModel());

$view->render();
Template:

Code: Select all

<h1><?php $this->paintTitle() ?></h1>

Data you gave us: <?php $this->paintSomeData() ?>
So basically the sequence of events in terms of program flow is:

1. Model created and given to controller
2. Controller makes changes to model based on external factors
3. Controller gives modified model to View
4. View renders a template

I mucked around for a while before coming up to this point (which is still a bit ad-hoc) and I admit that figuring out what goes in the layers is tricky initially, especially between Controller<->Model and View<->Controller. i.e. It's easy to let the controller do things it shouldn't do.
Post Reply