I am doing a Windows C# application.

I asked this question and I was told that the viewer/presenter should never know anything about the model. Does this mean that I should not add a reference of my model to the GUI I am making and instead of, lets say List<Car> I should transport the information using only strings and ints e.g. Dictionary<carID, carName>?

Because of the fact I am using EntityFramework, half of my domain model are basically in the DAL and rest are in the BLL and then I would need to add reference to both those layers. Is this the approach or am I doing it wrong?


I think thorsten müller worded the answer in a way that might confuse people (although his answer is good).

He says

The view never directly acts on the model layer.


the view should really have no knowledge about models.

Both of these statements are true, but allow me to clarify.

When thorsten says that a "view never directly acts on the model", what he means is that a view should not be manipulating or interacting with the model in any significant way. All the view should be doing is reading the properties that it has been given and displaying them to the user.

"view should really have no knowledge about models" means that a view shouldn't know the inner workings of the model. It doesn't really know what they are or how they got their values. Instead, you pass a model to a view and the view says "I don't really know much about this thing, but I see it has properties so I'll just render them".

Things get a little more debatable though, especially because we can use the term model incorrectly. What thorsten might also mean is that views generally don't know about the domain model.

Suppose you have an application for displaying information about University classes. You have teachers, students and courses. In some MVC applications the view will not reference these models and will not understand what they are directly. That is, you cannot give the view these models. Instead you would create appropriate ViewModels. You might create a StudentViewModel or CoursesListViewModel. You'd populate the view-models easily with something like AutoMapper.

Furthermore, thorsten might also mean that views should be generic. Many times in MVC applications when I notice that views and models are very similar (for example an edit form) I don't use separate views. Instead I send my models to a single view (perhaps "_EditForm.cshtml" partial-view) and the view will automatically generate everything required based on the properties of the view-model. The code never needs changing - I simply feed the view a view-model and it decides what will need to be rendered. I achieve this with ModelMetaData, attributes and reflection.

This is more intermediate MVC programming and will be a bit overwhelming for beginners.

Does this mean that I should not add a reference of my model [...] I should transport the information using only strings and ints e.g. Dictionary?

No. This would get very ugly and difficult to maintain. Referencing models or view-models is standard practice.

  • What you say about ViewModels is true. Don't know about the generic views, though; I've never heard of anyone actually genericizing views in this fashion, except for simple key/value administration. I'd love to see an example, or a link to one. There's no such thing as complete decoupling; the View always knows something about the model, even if that knowledge percolates through three layers of architecture. Otherwise the view wouldn't mean anything to the user. – Robert Harvey Dec 8 '13 at 23:18
  • "the View always knows something about the model" Yes. I've updated my answer to clarify this, thanks. Generic views are great fun, but they're a bit unwieldy so I need to remind myself to use them sparingly. They're just a combination of partials and display/editor templates. I'd love to put a solution together and create a new question+answer on StackOverflow or a blog post (if only I had a blog). – Rowan Freeman Dec 8 '13 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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