What does your Data Access Class look like?

We use Entity Framework as our Data Access Layer.

We previously used a repository pattern, with classes which accessed the database using Enterprise Library Data Application Block and accepted and/or returned Data Transfer Objects.

In some cases we have achieved a saving of 90% by using EF.

I use a homemade DataAccess layer and it looks like this:

public class HoneyOpposumDAO : DataAccessObject<lots of generics> { public ICollection<HoneyOpposum> Select(Filter filter); public ICollection<HoneyOpposum> Select(); public HoneyOpposum FindByApplicationId(int id); internal HoneyOpposum FindByDatabaseId(int id); void Register(HoneyOpposum o); void Commit(HoneyOpposum o); void CancelEdit(HoneyOpposum o); void Save(); void Save(Filter filter); void Save(DbTransaction transaction, Filter filter); void Revert(); void Revert(Filter filter); void Revert(DbTransaction transaction, Filter filter); } 

Filters are composite structures to express Filter Expressions in DataSets.

Basically, this is a three-tier DataAccess layer :

1. Business objects (model)
2. DataSets
3. Saving structure

Business objects have to register themselves using Register. Modification to these objects are confirmed to the model using Commit and can be undone using CancelEdit.

Commited business objects can be saved to the underlying saving structure (e.g. SQL Server) using Save and all changes since the last Save can be undone using Revert.

This DataAccess layer ensures control on saved and unsaved business objects. It also allows for seperate database and application ids.

Unfortunately, the underlying code quite complexe... and copyrighted :)

Call me nuts, but I never use any ORM toolkit. The reason is that I'm a control freak, and writing all the data access by hand allows me to always be able to modify it according to my needs, for example fine tuning lazy load functionality, etc.

So what goes in the DA classes. Well basically, the DA classes contains functions like this

void Save(DomainObject obj) DomainObject Get(int id) IEnumerable<DomainObject> Find(SomeQuery) 

So what goes into and out of my data access classes are Domain objects. So the DA has the responsibility of mapping domain objects to their database representation. In a project I'm currently working on, the client application can pass Lambda expressions as a query. So I can write something like this

IEnumerable<User> users = userDataAccess.Find(usr => usr.FirstName.StartsWith("Pete")); 

I will never make them static. Instead I will define the functionality in an interface, and let the calling code reference the interface. This allows me to use Inversion of Control and Dependency Injection. Two important concepts for having a testable application.

In this day and age most projects cannot justify writting thier own data layer. I would highly recommend using an existing solution. Sorry for the answe that is not an answer.