Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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!

share|improve this question
up vote 1 down vote accepted

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

share|improve this answer
Ok, that sounds fair. I've got to read up on these more, but the same question applies. Is it considered normal for external code to directly manipulate the View? – Luke Nov 29 '11 at 22:00
In above mentioned patterns, Presenter is one that does it. Commands and changes the view and reacts to external events as well. They have subtle differences, but are fairly similar. Look it up at, one of the great articles (more than one, probably, but I remember one) there is on this topic. – herby Nov 29 '11 at 22:05

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.