14

I was originally going to make this a longer question, but I feel like the shorter I make it, the better you'll understand what I mean.

  • The MVC architectural pattern has 3 dependencies. The View depends on the model. The Controller depends on the View and Model. The Model is independent.

  • The Layers architectural pattern defines N - 1 dependencies, where N is the number of Layers.

Given three Layers: Model, View, and Controller, there are only 2 dependencies, as opposed to 3 with traditional MVC. The structure looks like this:

View ---> Controller ---> Model

[View depends on Controller, Controller depends on Model]

It seems to me that this style accomplishes the same goals and produces looser coupling. Why isn't this style more common? Does it truly accomplish the same goals?

Edit: Not ASP.NET MVC, just the pattern.

With regard to griegs's post:

  • As far as mocking, Layers still allows you to use the Command Processor pattern to simulate button clicks, as well as any other range of events.
  • UI changes are still very easy, perhaps even easier. In MVC, the Controller and View tend to mesh together. Layers creates a strict separation. Both Layers are black boxes, free to vary independently in implementation.
  • The Controller has 0 dependencies on the View. The View can be written, and time can still be saved with loose coupling.
Mike
  • 19,267
  • 11
  • 56
  • 72

8 Answers8

16

Because you decouple the interface from the controller making changes easier.

Also consider the scenario where you need to get started on a project but the artwork won't be ready for weeks or months. Do you wait or do you write all the code required for the pages and simply then wire up the view to the controller.

At least that's what we did and we saved months.

Also it made UI changes easier to cope with because there wasn't any code in our aspx pages that did anything.

Our tests were also better as we could mock up anything including button clicks etc.

And if you're talking about the asp.net-mvc framework, there is no code in the aspx files and no viewstate etc.

griegs
  • 22,624
  • 33
  • 128
  • 205
  • You are assuming he is referring to ASP.NET MVC, not the MVC pattern, which is what he asked about. – Andy_Vulhop Sep 02 '10 at 01:15
  • 12
    No i'm not. Only in my last sentance am I doing that and I even say "If you're talking about..." – griegs Sep 02 '10 at 01:19
  • The view and the controller and inherently coupled in MVC anyway. Since both are modeled as black boxes, each can be mocked and/or modified. I don't feel you pointed out a difference, so much as similarities. – Mike Sep 02 '10 at 01:20
3

In proper MVC the controller doesn't depend on the view afaik. Or maybe I'm not understanding it correctly.

The model defines the data.

The view defines what the output looks like.

And the controller is a translator from a model-understood grammar to view-understood grammar.

So essentially the controller is independent. The view is independent. And the model is independent.

Yes? No?

Swizec Teller
  • 2,322
  • 1
  • 19
  • 24
  • This was my impression: http://prajwal-tuladhar.net.np/wp-content/uploads/2008/10/mvc-architecture.png – Mike Sep 02 '10 at 01:18
  • 2
    Each is (more or less) independent, but you have the role of the controller wrong. The controller basically takes user input, and modifies the model or view accordingly (though some implementations bypass the controller for actions that only modify the view). – Jerry Coffin Sep 02 '10 at 01:39
1

I'll be bold, and try to explain why your method didn't catch on.

The MVC pattern basically requires the view and model layers to agree on an API. Since one serves the other and there are no dependencies inside the code it leaves the controller to behave generically, all it needs to do is take a certain structure in the view layer and call the matching API on the model layer.

You'll note that agreeing on an API between the view and model isn't really such a big deal it has to happen anyway. And what you get is good separation between back-end front-end development.

In your proposed solution a lot of development is required on the controller side. The controller will be required to understand all the elements in the view and to map them to the specific calls required on the model layer. Since the controller is a single access point connecting many views to many models this can quickly get out of hand and end up being an incomprehensible controller module.

Look at some Struts2 examples to see what I mean...

Asaf
  • 6,384
  • 1
  • 23
  • 44
  • The Controller layer requires absolutely no dependencies to the View layer. In fact, the pattern restricts it. Also, MVC states that there is one Controller per View, with multiple Views, and one Model. So that is taken care of too. – Mike Sep 02 '10 at 01:45
  • So if I submit a form on the web page (view) how is the appropriate business logic applied (model)? If your view and model are truly independent the controller must have a definition of: ( input1 --> call methods 1,2,3 ) ( input2 --> call methods 2,3,5 ) ... I believe this is what most implementations of the pattern are trying to avoid – Asaf Sep 02 '10 at 01:51
  • If methods 1, 2, 3 are Model methods, ironically, yes, I am trying to achieve this. It makes a lot of sense. Smells even like an easy clean up for the Command pattern. – Mike Sep 02 '10 at 01:55
  • So by saying you would use the Command pattern how is this different from MVC? I would write a form with inputs A,B & C this will be read by the controller and result in a call to A.call() , B.call() & C.call() on the model. Am I getting it wrong? – Asaf Sep 02 '10 at 02:20
  • Nope. You're getting it exactly as I imagined. In this version, View has 0 dependencies on the Model. It then becomes Layered, not MVC. – Mike Sep 02 '10 at 02:24
1

I think I'm understanding your point:

Yes you can make the View only depend on the Controller only by making the Controller transform (using PHP as an example) the Model objects to non-Model objects like simple arrays.

As we already know, performing this transformation can be more effort than it's worth if the decoupling isn't actually needed. If the View uses the Model objects then it has this dependency. However, this can be relieved a bit by having the View depend solely on the Controller for its required input, which can be Model objects.

The Symfony PHP framework promotes this style of skinny controller shuffling between Model and View. You can still directly call upon the Model layer to retrieve objects within the View layer but it's strongly urged against for the coupling issues you bring up. Within the View you can call include_component() which actually goes back up to the Controller if you need to query the Model.

Rob Olmos
  • 2,372
  • 15
  • 24
  • Yep, you've got it spot on, @Rob Olmos. So it is used sometimes. I'm just surprised it isn't used more, especially given that for a while no one really understood what I was talking about. – Mike Sep 02 '10 at 11:44
  • Even in my org we're still debating whether to force the Controller to pass only non-Model variables to the View.. No decision yet but we're trialling it for feasibility... – Rob Olmos Sep 03 '10 at 03:12
1

I haven't gotten back to this in a long time, mostly because I was still thinking. I was unsatisfied with the answers I received, they didn't really answer my question.

A professor, recently, did steer me in the right direction. Essentially, he told me this: Layers which separate Model, View, and Controller is MVC. In the vanilla MVC architectural pattern, the dependency between the View to the Model is often not used, and you effectively end up with Layers. The idea is the same, the naming is just poor.

Mike
  • 19,267
  • 11
  • 56
  • 72
0

Choosing a presentation pattern for a new or enterprise web development on the Microsoft platform is a daunting task, in my opinion there are only three; View Model, Model-View-Presenter (MVP) or ASP.NET MVC (a Model2 derivative).

You can read the full article here ASP.NET MVC Patterns

MetalLemon
  • 1,390
  • 11
  • 16
0

I'd like to add some more things. First of all for my point of view is we use the model as container for the information we want to pass and show on the view. Usually the action method into the controller ends with return view("viewName",model).The view itself probabily will change its layour against the model :

on the view :

if(model.something==true) {

%>

somethign to show

<%

}

At this poinf the definition of model is hard to find.

I can say (especially on enterprise conext) the are two "model"

one is the domain model/entity model or how you want to call it that wraps the data coming from the lower layers (database,etc) and the view-model who contain the information we wants to show plus any other information we need to hide/show portion of interface

The controller orchestrate the the views and is indipendent from the view but a bit dipendent from the model:

into the controller

pulic actionResult Index(){

....

if(model.BoolProperty==true){

return ("firstView);

}

else

{

return ("secondView");

}

}

I hope it makes sense

Massimiliano Peluso
  • 26,379
  • 6
  • 61
  • 70
-2

In my opinion ,you'd better try it in your programme , you can use ruby on rails ,or codeigniter( for php ),these great framework may be helpful to your understanding the MVC.

keepyouliking
  • 1
  • 1
  • CakePHP is also nice MVC framework for PHP. With Perl, you may try Catalyst. .NET and Java, well, I guess everybody already knew the big names :) – Michael Mao Sep 02 '10 at 01:56