I’ve just read a great article in MSDN Magazine online:

Anti-Patterns To Avoid In N-Tier Applications by Daniel Simmons

It does claim to be about building applications that use the Entity Framework, but forget about that, it’s a great article that applies to any n-tier design.

Six ‘anti-patterns’ are covered:

1. Tight Coupling
2. Assuming Static Requirements (i.e. the customer knows what they want in advance)
3. Mishandled Concurrency
4. Stateful Services
5. Two Tiers Pretending To Be Three
6. Undervaluing Simplicity

So what is an anti-pattern? It’s just an example of a bad way of doing things.

I’ve witnessed countless horrible situations which could have been avoided by avoiding each of these anti-patterns.

Tight coupling: Systems where every bug fix generates new bugs (sometimes hundreds). Dev teams end up in an endless cycle chasing their tails and everyone with an interest in the product from the developers to the customer gets upset.

Assuming Static Requirements: There are so many situations where it is obvious that a change in the spec is likely to happen at some point the future. Designing a system to be tolerant of change reduces the risk of having to do some serious reworking, or even binning the whole thing and starting again. Sometimes this can be as simple as just storing lists in a database that can be added to instead of hard coding them.

Mishandled Concurrency: This can be a nightmare. Customers start complaining that their data disappears or isn’t right – sometimes. A related and even harder to track down issue is mishandled threading. This is a big area, but here is one tip: do not wrap database connections in a singleton in a multithreaded app. It will break.

Stateful Services: Complicated and time consuming to build, don’t scale. Enough said.

Two Tiers Pretending To Be Three: I have seen so many systems which started out with grand 3-tier intentions and after about five minutes the business logic is spread out all over the place. Some of it is in the middle where it should be, some of it is in the UI and some of it is in stored procedures in the database. And there is SQL in the UI. And there are pieces of UI in the database (as is stored procedure gets some data, applies some business logic to it and returns HTML which goes through the middle, possibly getting modified along the way and inserted into the rest of the UI). Nasty to debug. Nasty to change. Nasty.

Undervaluing Simplicity: I just cannot face another complex solution to a simple problem. I get the feeling that some developers like to create complex solutions to somehow prove that they are smart. The smart thing to do is keep the simple simple. Here’s a quote from Tony Hoare (the creator of QuickSort): “The pursuit of complexity is easy, and the implementation of complexity can safely be delegated to competent managers. But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind.” - Challenge yourself every day.