What are the key anti-patterns to avoid when architecting applications for the enterprise? We are using C# and SQL Server and Silverlight, btw - but I imagine some of the anti-patterns will be language neutral.
Asked
Active
Viewed 2,407 times
7
Rachel
- 100,387
- 116
- 269
- 365
Craig Schwarze
- 11,367
- 15
- 60
- 80
-
4Some might consider Enterprise Architecture itself an anti-pattern. – cletus Jan 11 '10 at 03:45
-
I wouldn't think this is community wiki, but happy to be guided – Craig Schwarze Jan 11 '10 at 03:46
-
This is a very subjective topic (there is no absolute right answer), so it should probably be CW. – Rex M Jan 11 '10 at 03:48
-
Agree, this should be a Community Wiki (I've marked my answer as such). – jason Jan 11 '10 at 03:53
2 Answers
6
Wikipedia is quite comprehensive on the subject of anti-patterns and here's the book on the subject: AntiPatterns.
Top five in my experience:
- Premature optimization
- Anemic Domain Model
- God object
- Golden Hammer (cf. regular expressions)
- Chain Gang
-
-
1That anti-patterns catalog is full of frivolous entries and bike shed discussion. – Rex M Jan 11 '10 at 03:51
4
Enterprise sinkhole:
1: read that your database access should be in a separate layer
2: Hey, we've got a database layer.
2(b) Hey, we've even got a delegate layer to abstract away our database.
3: Apply the law of leaky abstractions-i.e since there are methods in the delegates that get things, just assume they're there to use with no thought to the consequences - as in call "getPurchaseOrder()" 10 times in succession on a page, even though getPurchaseOrder() is a method that wraps 5 separate database calls.
4: Sit back and Enjoy your web pages that load with 100 separate database calls (sadly, not an exaggeration).
Not sure what I'd call this as an antipattern? maybe "Layers aren't free"?
Steve B.
- 55,454
- 12
- 93
- 132
-
Separating data access concerns from the rest of the application does not necessarily result in the primitive repository pattern you're describing, with get and set methods for every kind of entity in the system. It's disingenuous to suggest #s 3 and 4 are natural consequences of #s 1 and 2. – Rex M Jan 11 '10 at 04:46
-
1@Rex - they may not be natural consequences, but they certainly are an antipattern. Something that happens frequently enough to consider warding against. – Tom Jan 11 '10 at 05:10
-
1@Rex, I understand an antipattern to be a negative pattern that code can fall into. What I'm thinking of here is the coding against layers without being aware of, or thinking that you have to consider, what they're actually doing. e.g. given my example above, You then see (well, I've seen, anyway, people write a line like: if (getPurchaseOrder()!=null && getPurchaseOrder().price>10). – Steve B. Jan 11 '10 at 11:59