There are several levels of thinking when it comes to design patterns and even more so when you add into the mix a database.  I for a long time have been a fan of ORM designs, starting with my first introduction to the concept back in 2005.  At that time the method of thinking was that it was best to generate the structure of the DAL using code generation.  At the time the one that we were using was .net tiers with a product called CodeSmith.  Over time I have delved into several packages including nHibernate, MyGeneration (DooDads.net), tt4 tempates, and the latest entity framework. The importance of generation of the DAL can not be underplayed as much of the code that is involved at this level of the project is terse and repetitive.  Because of this it is generally rife with crtl-c, ctrl-v errors as well as inconsistent patterns.  Lets face it no one likes writing the same method over and over again, and because no one likes it it very seldom gets the real attention that it deserves. All of this included is one of the reasons that I am starting to become more and more of a fan of the .net frameworks built in Entity Framework.  In many ways it allows for the quickest and most forward method of auto generating a DAL. The main reason for this is that the generation of the code happens at design time within visual studio.  This point can not be emphasized enough. Database flexibility and the ability to change designs on a dime is a must when you are talking about developing greenfield enterprise applications. In every project that I have gone into there is always one person who is brave enough to say that they know exactly what the data should look like and because of that there is no need for flexibility.  Inevitably there are always changes for one reason or another. Since we can treat change as a constant the main thing that we have to take into account is how do your reduce the amount of pain associated with that change. I believe in order to get the most flexibility to change the key would be to write as little code as possible. If this is the metric that we are using, the code generation should always be the answer.  If we take the more stringent approach and change the metric to the least amount of time from database change to updated code, I think that entity framework win hands down. With entity framework there is no exiting visual studio to generate the code, there are no xml files to edit.  This is the essance of what it means to have a agile database and data layer. Beyond this  it offers natural protection from SQL injection attacks, without relying on developers to know the change and account for the nature of the framework. So when you set down for your next project and you are about to write you first CRUD Function, don't do it. Find a good ORM, in the end you will appreciate the time that it saves you.