Why seperating the View / Controller is important

time to read 4 min | 716 words

On my Castle.Igloo post, Jonathan Allen asks in a comment:

I don't understand why you think you have a problem. Consider these passaged from the original definition of the MVC pattern:

"Communication between a view and its associated controller is straightforward because View and Controller are specifically designed to work together. Models, on the other hand, communicate in a more subtle manner."

"Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling."

-- Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC)

Notice how it explicitly says that there will be a tight coupling between the view and controller.

While your view of MVC is shared by many, I have a hard time reconciling it with the original definition. They are not just variants; they are on literally opposite positions in regards to coupling.

I would like to hear your position on exactly what the MVC pattern is. And if it does in fact differ from the original definition, the reasons why you think the 'new' definition is better.

I think that it boils down to the fact that I have at least some MonoRail experiance, and I tend to think about stuff a little differently about those things now. I mainly focus on seperating the controller from its views, this is done because in WebForms, the other way is not really possible (at least not with a lot more magic, at which point you are with MR but with WebFroms, in which case it is better to use MR in the first place). Seperating the controller from the view helps when you want to unit test it, for instance, or reuse it in a different context.

 As for a concrete example for why I would want this speration, here is a simple example:

I have PostsController, which should display a list of posts for the user. This means that I have ViewPosts.aspx page, and because I am using Atlas, there is also a web service over JSON that is used by the page to page between the pages dynamically. Doing this in the traditional way would force me to create two controllers, PagePostsController and WebServicePostsController. But I don't see much point in splitting the responsability. Using Igloo, I can reuse the PostsController in both views, since there is no dependency on a view.

Evne if I assume that I had used an interface to seperate things, I would still get issues, because the Page and the WebService has distinctly different charactaristics. In tests, I could test the controller fully, without needing to mock the view, which makes my job much easier.

The reverse option may be a page that needs to list several things, so it may want to use several controllers (PostsController, CommentsController). I am not sure if this is a good idea yet, but that is possible with Igloo, and I think that it make sense, at least on the surface.