views:

156

answers:

1

I'm fairly new to ASP.MVC. For our new Web application I'm considering between two options for view engines:

  1. Using some of the available view engines (the default one, NVelocity, Brail, etc.) as a primary view code generator.
  2. Implementing an application-specific C# DSL for generating HTML code so that the main bulk of the view code is stored in C# classes (using some sort of smart HTML generation like the one described by Jimmy Bogard).

The idea behind 2. would be to reduce the need for writing direct HTML code each time a new view is needed, but I'm not sure if this is a good approach. One drawback of it is that it would not be possible to change the generated code without recompiling the project.

What do you think?

+2  A: 

I've seen approaches like this used in other projects, and in general they're more trouble than they're worth. The flexibility you lose is just too high a price to pay for the automatic-ness of the generation phase. Think of how often requirements turn out to apply just to one special case, and now imagine how you'd have to handle that here.

Additionally, if your views are causing you that much pain, I would suggest you might not be using views correctly. You should see very little repetition in your views across the site. Common pieces should be refactored into separate chunks and pulled in from there, for example.

John Feminella
OK, your point about flexibility is a valid one, although the amount of flexibility you need depends on the nature of an application. For example, you could have a Web application that has a lot of Web pages which are fairly similar to each other, with just a different types of data fields shown (let's say it's a wizard-like, just for the sake of discussion).
Igor Brejc
-1 This works extremely well in Seaside. So it can be done right.
Stephan Eggermont
Stephan: I never said it couldn't be done right, just that it's possibly suggestive of a bad idea. In general, frequent repetition can be a code smell.
John Feminella