Wednesday, November 08, 2006


How Not to Implement a Data Layer

If you are creating a new application with a clean slate, please don’t do what a developer I had first hand experience with did. This is the sort of material I would expect to find on the daily WTF!

Warning! Coding Horror follows. Don’t do this!

1) Ridicule code generation saying it won’t work, and that no one is using it anywhere. Reject the fact that several industry luminaries with great architectural experience have designed excellent code generated frameworks. Don’t generate anything. Do it all by cut and paste. Write your stored procedures by hand, despite the fact that 90% of them have a similar structure.
2) Design and implement your own less than optimal scheme for a data access layer and business logic layer, despite the fact that a quick internet search and a few hours reading would quickly show you the gaps in your knowledge. When I say less than optimal, what exactly do I mean? How about using reflection between your data access and business logic layer! Oh and while you’re at it, for good measure create your own non industry standard nomenclature, just to make it more confusing.
3) Ignore advice on inheriting from BindingList instead of List; plus completely ignore the fact that you probably will want to implement an event driven model for your object classes.
4) Create Load methods that can take different types of keys (think table primary key and rowids in Oracle). Pass one type of identifier to some methods, and the alternative to others.
5) When challenged to justify your design decisions say you did it that way in C++!
6) I could continue, but I think you get the idea…

You should definitely consider one of the many good tools already available for generating DALs and BLL stubs. Several are free, such as CSLA by Rockford Lhotka (buy the book, it’s a sound investment), MyGen, NetTiers 2.0 (although you will probably need to buy CodeSmith). Others require you to part with money such as the (IMO, poorly named) LLBLGEN Pro which has a stack of ORM features, and Wilson OR Mapper to name but a few.

I’ve spoken to one or two people recently who were amazed that someone with 10+ years of experience could do something like this, which is the reason I decided to post. It all comes back to Ego. The better programmers are usually the ones with the smallest egos. OK, I feel better having got that off my chest!


Powered by Blogger