Designing a Generic Database Layer

re: Designing a Generic Database Layer

Mike Gale — Sun, 13 Jan 2008 22:23:25 GMT

What fascinating responses. (A response often tells you more about the person who wrote it than about the article they comment on!!)

I'd appreciate a follow up on the impact of this approach (maybe a couple of ORM's thrown in too) on real projects.

(It would be great to see issues like code readability, time to get back up to speed (after a break), making changes, LOC and time taken, addressed. But I know, it's nearly always impossible.)

re: Designing a Generic Database Layer

Jesse Ezell — Fri, 11 Jan 2008 12:26:08 GMT

JV,

I've seen far too many bad design decisions made because something is theoretically "less work." That is a really hazy term. Less code does not always equal less work. I've used ORM tools and I've used the approach described here, and my experience in taking projects through their full life cycle tells a different story.

However, this post was not to discuss whether or not to use ORM. If you've had success with ORM on the type of projects you are involved with, more power to you. There are situations where ORM makes sense.

re: Designing a Generic Database Layer

Jesse Ezell — Fri, 11 Jan 2008 12:11:51 GMT

Ramon,

A. Maybe you could clarify what you are trying to say here and state what is bad, instead of asking a question in the form of a sentence fragment.

B. You can easily provide multiple overloads for a method, one taking only required parameters and one with required and optional parameters. This is just a simple sample.

C. Your question tells me you haven't aren't familiar with generics. default(T) used with a reference type returns null, so you would check for empty as you normally would. (http://msdn2.microsoft.com/en-us/library/xwth0h0d(VS.80).aspx)

re: Designing a Generic Database Layer

JV — Fri, 11 Jan 2008 10:22:14 GMT

An ORM is much more then just a database layer imao. Besides that I totally agree with Ramon. The DAl you have created isn't very flexible. It will actually require more work then when you would be using an ORM. And let's be fair, with LINQ To SQL and the upcoming Entity Framework ORM in .NET was never this easy...

re: Designing a Generic Database Layer

Ramon Smits — Fri, 11 Jan 2008 08:35:00 GMT

You really should take a look at projects like NHibernate because I see a couple of bad practices in your examples.

A. Using a fixed result stored procedure to initialize a custom type?

B. Your "CreateCustomer" method is not flexible. What about optional fields? This could be a constructor for the Customer class.

C. Returning a default Customer instance when NO record is found in the database? How to check if data is returned then?

re: Designing a Generic Database Layer

Jesse Ezell — Fri, 11 Jan 2008 07:16:21 GMT

Regardless of your opinion on the issue, this naming pattern is pretty commonly used and accepted.

Just ask Microsoft:

msdn2.microsoft.com/.../microsoft.commerceserver.marketing.customermanager.aspx

or BEA:

edocs.beasys.co.jp/.../CustomerManager.html

re: Designing a Generic Database Layer

foobar — Fri, 11 Jan 2008 07:02:24 GMT

I'd throttle you and kick your butt to the curb if you ever worked for me and made a class called "CustomerManager". Could you make a more generic name for a class?