I'm fairly new to ASP.MVC. For our new Web application I'm considering between two options for view engines:
- Using some of the available view engines (the default one, NVelocity, Brail, etc.) as a primary view code generator.
- 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?
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.
来源：https://stackoverflow.com/questions/819667/asp-mvc-implementing-a-non-templated-view-engine