R – Abstracting Data Access Layer from Business Object

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?