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?
I suggest the Repository Pattern
