Antipatterns with ASP.NET

Question

What are the most common Antipatterns you see in ASP.NET applications and how should we avoid them?

Answer 1

Doing work on the server that should be done on the client

Just because ASP.Net makes it very easy for an input to post back to the page doesn't mean that you should- post backs are expensive. The server has to run a lot more code than just the event for the postback.

To avoid it, think about every server-side event and ask yourself how you could do it at the client (perhaps with javascript) instead.

Answer 2

WebForms.

Avoid by using MVC.

:)

NOTE: this is only partially a joke, because WebForms / HttpContext is a beast of a class that is next to impossible to test and the MVC model is designed for testability because most of the classes derive from interfaces.

Answer 3

Big code behind files. The temptation to shove all your code into code behind ends up mixing lots of concerns together, limits maintainability, and almost completely removes your ability to unit test your page's logic.

Answer 4

Failure to understand the impact of ViewState

Everything in viewstate has to be submitted from the client to the server with each postback. For an intRAnet site it may not be a big deal, but for an intERnet site the bandwidth available for transmitting this information is often very small (even if your users all have broadband), to the point that you're probably better off keeping most of it in a database.

To solve this, it's probably a good idea for new ASP.Net developers to get used to working with ViewState disabled, and only turn on specific pieces for things that don't work as expected. As they come to have a better understanding of ViewState it's okay to turn it on again (unfortunately, for shops with significant developer churn this may mean needing to have an "always disabled" policy).

Answer 5

Treating ASP.Net like Classic ASP

The worst case of this is trying to use old ADO objects for data access, down to calling CreateObject() to get a record set.

Styles vary from place to place, but in general there shouldn't be that many "beestrings" (<% %> and the like) in your .aspx markup (databinding expressions being the notable exception).

Instead, use a code behind or custom/user controls to bring your server code into the markup.

Answer 6

The God Object pattern, also very frequently code is written at maximum coupling that it's not possible to unit test anything well or even at all.

I do not agree with disabling the view state for pages though. The viewstate is an important layer in the page life cycle, it doesn't make sense to make pages be stateless by removing the viewstate unless you are implementing the MVC framework.

Answer 7

WebForms makes it easy to have your DataAccess, BusinessRules and User Interface all in the code behind which makes for a maintenance nightmare. You can write clean code with WebForms but it's very easy to shoot yourself in the foot.

Answer 8

Definately sticking everything in code behind.

At work, past development has been done like this. Because there is no passion or drive to find the best technical approach (e.g. MVC), and the main concern is the business side of things - system pricing, meeting deadlines, and that the functionality works - but now how - this is the habitual way of doing things. It's also the lazy way.

On top of that, a general anti-pattern but which I've seen in past development at my company is sequential code (ugh).

Answer 9

Well my answer would be partly related to the ones given before me. What I've noticed in several occasions is the extensive use of Session. Even for scenarios where ViewState is good, or can be avoided altogether. This maxes out memory on the server and raises a thousand other issues.

I also agree about going too far with ViewState.

Another thing is the use of UserControls for custom solutions, instead of Composite or Custom controls. To me UserControls should only be used in the simplest scenarios, otherwise maintainability suffers.

Answer 10

The worst things I see in projects nowadays:

1. Too much loosely typed objects. Solution: Use a generic collection
2. Very big viewstates. I have seen viewstates that are several mega bytes.. Solution: Don´t use it too often, or use ASP.NET MVC.
3. Really big methods. Solution: Use inheritance, refactoring and so on.
4. Too many LOC in code behind files. Solution: Use class libraries with the logic, and maybe a facade layer which you can call from the code behind.
5. No use of parameters when working with a database. Solution: Use a O/R Mapper or IDbCommand.

Answer 11

The void SetupPage() method.

We spent much of the last half of 2008 cleaning up these methods in our codebase. Developers were aware that sticking massive amounts of code in Page_Load was bad, and so tried to factor it out into a number of private methods which over time ended up as SetupPage().

Developers approaching these pages later would see a 1000+ LOC code behind, panic, and stick everything else in any random method which seemed to execute at about the right time.

I pretty much flipped my lid when I came across a 50+ line switch statement for show/hiding UI elements nested in the ApplyAuthorisationRules() method (called by the DataSource_OnSelect event). see vastly over-complicated, view-state dependent pages with horrendous HTML layout.

Answer 12

Referencing HttpContext, Session, or Anything else From System.Web in the Business Layer
This is a big no-no that I've seen on many projects. The business/domain layer should be agnostic what presentation platform the application is built upon be it webforms, MVC, asp.net MVC, WPF, etc...