Who can change the View in MVC?

Question

I'm working on a thick client graph displaying and manipulation application. I'm trying to apply the MVC pattern to our 3D visualization component.

Here is what I have for the Model, View, and Controller:

Model - The graph and it's metadata. This includes vertices, edges, and the attributes of each. It does not contain position information, icons, colors, or anything display related.

View - This would commonly be called a scene graph. It includes the 3D display information, texture information, color information, and anything else that is related specifically to the visualization of the model.

Controller - The controller takes the view and displays it in a Window using OpenGL (but it could potentially be any 3D graphics package).

The application has various "layouts" that change the position of the vertices in the display. For instance, one layout may arrange the vertices in a circle.

Is it common for these layouts to access and change the view directly? Should they go through the Controller to access the View? If they go through the Controller, should they just ask for direct access to the View or should each change go through the controller?

I realize this is a bit different from the standard MVC example where there a finite number of Views. In this case, the View can change in an infinite number of ways. Perhaps I'm shattering some basic principle of MVC here.

Thanks in advance!

Answer 1

What you describe is more akin to MVP, Supervising Controller or Passive View.

Answer 2

I'm most familiar with Microsoft's ASP.NET MVC implementation. MVC does not apply separation at the level you describe.

• Model is essentially a data layer model. It's not directly tied to the database tables (bad practice), but it's close.
• View is where the UI lies. So if this is web, that would be HTML/JavaScript or really even C# (via razor in a View page...but you need to work with an MVC3 project for all that to make sense). My point is that its about the layering, not the languages. Windows based applications tend to use MVVM rather than MVC so I don't think there is a direct tie, but the UI is still basically the View.
• The controller is the middle man between these two.

There's not a lot more to it. MVC at it's core is a simple design.

You also need a business layer that works closely with the controller in all but the most trivial projects. MVC does not have a defined business layer and yes it is OK and normal to add your own.

Accessing from View > View directly is not something I've heard of anyone attempting to do, nor would I recommend it. For maintainability, you should create parallel layers for specific tasks. The view should be modified either by itself or by calls to the controller which in turn may call the model, business layer or some other intermediate layer.