I understand the reason for having the HTML helpers in ASP.NET MVC and extending this to provide your own, but I am wondering whether using HTML helpers is a good idea.
I thought one of the benefits of ASP.NET MVC is control over the HTML. If you start hiding it away in helper functions that generate HTML don’t you start losing visibility? I guess this isn’t such a problem when you are generating simple controls such as a button, but I have seen the use of html helpers to create grids and more complex HTML output.
Now I also understand the reason for doing so is to keep things DRY, avoiding duplication. But is there not a danger of having something akin to code-behind here? In addition, what if you are working in collaboration with designers? Generally the designer would be creating the markup and applying styling. If you start injecting your view with helpers that generate markup, doesn’t this make such collaboration difficult?
‘Control over the HTML’ is microsoft marketing-speak, and is how they are choosing to brand the platform. The point of ASP.net MVC is that it is a more simple, and a better fit for webapps then the whole stateful event-driven model of webforms, and something that pretty much everyone outside of the microsoft space moved to years ago. Microsoft can’t say that though, because they have a huge investment in webforms, and it is a key part of their enterprise story.
That being said, if you have business logic in your helpers you are using them wrong. It is basically code behind for presentation logic only that is duplicated across multiple pages, and the goal is to keep scriptlet tags in the markup as simple as possible.
As long as you use the helpers the way they should be used, it should be fairly trivial for the designers to learn how to use. Just remember that the goal is to keep things simple, if they end up making things more complex, it means they are not being used correctly.