Data Access "Architecture" question

[Fresno Bob]

Hi I'm creating a data access layer in which each object maps onto a
database table. I will also be creating basic methods that return the object
by primaryid and perform insert and update operations. I also will be
creating methods which return collections of the object. Where should I put
those methods that return collections of objects. Should I create a
Collections class that corresponds with each object which just returns
collections.

Bear in mind I am using CodeSmith and so would like a consistant place to
put the main object with it's properties and so forth and the methods that
will return collections.

Regards, Chris.

 

[Cowboy \(Gregory A. Beamer\)]

Wow, you sure opened a can of worms.

The pattern you are talking about is Active Record. In general, you put the
active record classes down near your DAL and use a provider model to
separate out different types of access. I say, in general, as I am sure
someone else has solved the problem in a different way.

One open source project you might look at is SubSonic. It will generate
Active Record classes and it uses providers to keep the physical storage
(SQL Server, Access, etc.) separate from the classes. Whether you opt to
stick with it, it might give you clues for CodeSmith.

As for the collection "problem", with an Active Record model, you are
probably best to choose to have a collection per object type. It keeps
everything one to one. You could opt for a generic implemntation, but you
really have to think that one out.

Be sure to use partial classes, as you will find reasons to extend your
generated classes at some time.