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.
+3
A:
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
Jason
2010-01-11 03:48:04
Thanks Jason - got any thoughts on the top 2 or 3?
CraigS
2010-01-11 03:48:54
That anti-patterns catalog is full of frivolous entries and bike shed discussion.
Rex M
2010-01-11 03:51:13
Thanks Jason - that's great!
CraigS
2010-01-11 03:53:07
+2
A:
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.
2010-01-11 04:10:13
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
2010-01-11 04:46:45
@Rex - they may not be natural consequences, but they certainly are an antipattern. Something that happens frequently enough to consider warding against.
Tom
2010-01-11 05:10:53
Steve B.
2010-01-11 11:59:36