Abstracting Data Access Layer from Business Object

Question

It's nothing new to de-couple the data access code from your business objects, but I'm always on the look-out for the "best way" to achieve something.

I have the following classes:

Orange - this is my Business Object.

OrangeList - this is a List of Oranges.

The user would fetch Orange objects from the data store by calling OrangeList.Fetch(someCriteria). Therefore OrangeList has to have a reference to the Data Access Layer - so it has the property: IDataProvider MyDataProvider.

This will work for me, but the problem is that we cannot fetch a single Orange by itself - we always have to go via OrangeList.

Either that or both Orange and OrangeList would have to descend from some common object that would hold the DataProvider.

Is this a problem, or is my approach WAY off the mark in the first place?

Any hints/pointers are appreciated, thanks.

EDIT: In light of the discussion below, I checked out the Repository pattern.

However for my project, I think it is a good idea to separate still further the Repository from the DAL.

SO.... The Repository is how I GET Oranges, and SAVE Oranges, but still doesn't know HOW. I delegate that to the IDataProvider, which could be a number of those listed in the diagram.

To clarify - Orange does NOT know how to fetch/update itself, right? It's a PURE business object - and is that the point?

alt text http://img22.imageshack.us/img22/2460/repositorya.jpg

In case you're wondering, my "LegacyDataProvider" is to support an OLD system, which accesses a file-based Database (FoxPro, eek) - but this lets me wrap this up and keep it at arms-length from my new code.

In terms of .NET assembly construction, to prevent circular references it looks like I'm gonna have a Repository.DLL [OrangeRepo], a DataProviderInterface.DLL [IDataProvider], and a BusinessObjects.dll [Orange]. All good?

Have I got the idea of the repository then?

Answer 1

I suggest the Repository Pattern

Answer 2

I would (and do) compose all these things off of a master API object (OrangeCart?) that also composes an interface object for the data access layer. Your Oranges and OrangeLists know that they belong to the OrangeCart and to talk to it for DAL operations.

Answer 3

Rather than OrangeList(someCriteria), I'd have Oranges.Criteria1List, Oranges.Criteria2List. For a singleton, I'd have Oranges.GetItem(orangeId).

Doing it your way, the BusinessObject ends up needing to think in logical data design terms rather than conceptual terms.

(Repository implementations cause me the same discomfort - too often all they are used for is to put a thin-abstraction thick-code layer over the tables. I don't like the BL to ever be required to know about database implementation details like data types and sizes. Too often it's useful to decouple these kinds of dependencies.)