SQL Server, Analytics, .Net, Machine Learning, R, Python
Mitch Wheat has been working as a professional programmer since 1984, graduating with a honours degree in Mathematics from Warwick University, UK in 1986. He moved to Perth in 1995, having worked in software houses in London and Rotterdam. He has worked in the areas of mining, electronics, research, defence, financial, GIS, telecommunications, engineering, and information management. Mitch has worked mainly with Microsoft technologies (since Windows version 3.0) but has also used UNIX. He holds the following Microsoft certifications: MCPD (Web and Windows) using C# and SQL Server MCITP (Admin and Developer). His preferred development environment is C#, .Net Framework and SQL Server. Mitch has worked as an independent consultant for the last 10 years, and is currently involved with helping teams improve their Software Development Life Cycle. His areas of special interest lie in performance tuning
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!
MSN, Email: mitch døt wheat at gmail.com