Is it bad practice to build a large web component as a Html Helper?

Question

So, from my understanding, Html Helpers are supposed to be for single elements or small snippets of html. However, I'm not really sure why I think this, or how I came to abide by the practice. I couldn't find anything from Microsoft that covers this topic either.

The reason I ask is that recently I've been asked to build a fairly large web component as a single Html Helper, that builds its html using nothing but TagBuilders.

This component will have many different elements; multiple wrapping divs, inputs, selects, and lists. For reference, it's an address entry control, but it supports choosing between entering manually or finding via postcode and selecting, and it allows for going back and editing the address. In total it has 5 different "views".

I feel like building this entirely with TagBuilders is going to result in unreadable markup. I'm only a small way into this task and it's already hard to tell at a glance what markup it produces - but I wonder whether that's because building a large amount of html with TagBuilders is bad practice, or whether I'm doing something wrong.

So is it bad practice to do this, and if so, why?

Answer 1

Yes. I would say that the static HTML helper style of control is a bit unusual and seen as bad practice unless you have a good reason to use it.

The reason being that you have to build the html in code rather than templating. which makes it troublesome to change and maintain.

The alternative would be a set of viewmodels and partial views. The downside being that they are harder to distribute as a single thing.

Another excuse for using the helper is to use (or abuse) the using(Html.BeginForm) syntax so that you get the closing tags automatically in

Answer 2

If you're questioning your code, then it probably means someone else will too. Always keep in mind the SOLID principles, specifically Single Responsibility. I've build large markup pages in the past, what I believe works the best is to have smaller components that make up the page. With Razor you can leverage partials.

Answer 3

To keep concerns separate and clean, it is advisable to not load server with lot of html building logic. I also had some doubt and found good article explaining why one would like to avoid so. Below is direct reasoning from that :

There are five reasons from my perspective, good enough to prefer a mature and well designed JavaScript framework versus ASP.NET MVC. This is not performance related at all. I will not come with reasons like 'ASP.NET MVC is a server side development framework so it imposes and extra load on web server due to rendering (Razor Engine or ASP Engine) while Angular has an impact strictly on client machine'. As you noticed, my favorite JavaScript framework is Angular and that is not because it was developed at Google, it is because I find it to be a very elegant and comprehensive framework, this is a subjective opinion any way. I will start to present my five reasons from the most superficial to the most realistic.

First reason of all, mixed code...I really dislike it, I really do. Even after so many years of working with ASP.NET (WebForms and MVC) I still can't accommodate with it. The look and feel of server side code embedded into pages (chtml pages in my case) is a true pain for my eyes. I find it difficult to follow the code logic and navigate through it. Not to mention the fact that some people can be really inventive when it comes to what server side code generates in the page.

The second reason is, OK this is strictly my opinion so I might be wrong about it, client code is for clients and server code is for servers, simple as that. What has to deal with client side, is mainly related to how data is retrieved, presented and how the end user interacts with it should be a client side code concern only (let the browser do its job). Same thing applies to server side, let the server side code handle all business logic, data persistence and all the another nuisance aspects, don't bother the server with concerns about how the information has to be presented and how the end user should interact with it. I always choose SOA approach for my applications which can be either SOAP either REST.

The third reason is, there is no way a designer (not sure if this is the most appropriate term for an HTML/CSS expert) will work easily on pages which have server side code embedded. The "why?" is quite obvious I assume. Unless you are lucky enough to have an experienced developer on both fields (HTML/CSS and ASP.NET MVC). The server side code is way too intrusive from my point of view, compared with how Angular works. The forth reason is, most developers do not pay same attention to both sides. How many times have you seen JavaScript code sprinkled in pages? How many times have you seen JavaScript functions flying around? How many times have you seen JavaScript code blocks without being encapsulated in a namespace? You know why? Because the main idea behind having server side code to generate UI is to cover the lack of strong skills related to client side development (JavaScript, etc).

The fifth reason is, you can't test it. Yes, you can't test the final result unless the server code works as it should. Imagine that you want to check if your page always displays data in a strictly defined order. Or if amounts or dates for example are formatted correctly based on client culture. What will happen if there is a bug on server side code which doesn't allows you to build the project, or something goes wrong on data access layer? Are you going to be able to test your page? I think not. Same thing doesn't apply if you have the client and server as totally separated tiers (as they should normally be, after all we are talking about client code and server code). You could easily mock the data needed in tests with JSON without carrying if the server is fine or not. You could easily do this sort of tests with Karma Test Runner for example.