Organising data access for dependency injection
- by IanAWP
In our company we have a relatively long history of database backed applications, but have only just begun experimenting with dependency injection. I am looking for advice about how to convert our existing data access pattern into one more suited for dependency injection.
Some specific questions:
Do you create one access object per table (Given that a table represents an entity collection)?
One interface per table?
All of these would need the low level Data Access object to be injected, right?
What about if there are dozens of tables, wouldn't that make the composition root into a nightmare?
Would you instead have a single interface that defines things like GetCustomer(), GetOrder(), etc?
If I took the example of EntityFramework, then I would have one Container that exposes an object for each table, but that container doesn't conform to any interface itself, so doesn't seem like it's compatible with DI.
What we do now, in case it helps:
The way we normally manage data access is through a generic data layer which exposes CRUD/Transaction capabilities and has provider specific subclasses which handle the creation of IDbConnection, IDbCommand, etc.
Actual table access uses Table classes that perform the CRUD operations associated with a particular table and accept/return domain objects that the rest of the system deals with. These table classes expose only static methods, and utilise a static DataAccess singleton instantiated from a config file.
