views:

47

answers:

3

Looking at examples and tutorials for some MVC libraries for web development on the Internet, I found that many of them construct HTML directly in the code of Model class and then Controller just sends it to the View which just displays it. While this makes Controller and View very simple and clean, I feel it is a wrong approach. IMHO, Model should just retrieve data, without having any representation logic in it. Controller should pass this data to the View, and View would contain the code that iterates through it and generates final HTML.

Is my thinking correct, or am I missing some important point here?

+1  A: 

Presentation logic is shared between the view (most of it) and controller. The model should not concern itself with presentation logic.

If it does, you don't have separation of concerns. This isn't inherently a bad thing, but you miss the advantages of having presentation and business logic separated. So no, it's not a good idea.

This being said, there are elements of presentation logic that may get to the model. Think of a cms. Idealy you would have all the data marked up, let's say xml, on which you would apply a template to deliver it. But the data, and the template are kept in the model. So what is presentation, and what is business here?

There are gray ares, but most of the times is easy to separate presentation and business logic.

Mercer Traieste
+1  A: 

Your thinking is absolutely correct. If you want a clean separations of concerns it is best to have the View generate HTML from Model. In some cases html helpers could be used.

Darin Dimitrov
+1  A: 

Is fetching HTML directly from Model (MVC) a good idea?

My gut instinct would say no. Breaks the concept of separation of concerns.

Colin Mackay