views:

58

answers:

2

Hi all.

In an n-tier architecture, the best place to put an object-relational mapping (OR/M) code is in the data access layer. For example, database queries and updates can be delegated to a tool like NHibernate.

Yet, I'd like to keep all references to NHibernate within the data access layer and abstract dependencies away from the layers below or above it. That way, I can swap or plug in another OR/M tool (e.g. Entity Framework) or some approach (e.g. plain vanilla stored procedure calls, mock objects) without causing compile-time errors or a major overhaul of the entire application. Testability is an added bonus.

Could someone please suggest a wrapper (i.e. an interface or base class) or approach that would keep OR/M loosely coupled and contained in 1 layer? Or point me to resources that would help?

Thanks.

+2  A: 

It sounds like you are looking for the repository pattern. If you need more decoupling, you can inject the data dependencies with an Inversion of Control container.

Robert Harvey
I'll also need data mappers or DAOS as the Repositories will be between the domain model and data access layer. See more details here: http://martinfowler.com/eaaCatalog/repository.htmlThe domain model will contain the Repositories, but can't hold a reference to the data access layer. Therefore, DAOs will need to be injected into the Repositories.My main goal is to make the base DAO class for each data access technology (e.g. NHibernate, Entity Framework, XML datastore, ...) inherit a common interface. That way, I can swap or mix them at will without recompiling or major rework.
Genuine
Sounds like you're on the right track.
Robert Harvey
A: 

Service Facade Pattern is one name. Simple contracts between business logic and data layer.

Service classes or beans (call it what you want) define and implement the contract, and orchestrate the lower data layer, often handling the transactional logic across data objects.

In Spring, you define an Interface, and then implement it. One implementation might be an OR/M, another might be raw JDBC or ADO.NET. In some frameworks, Aspect Oriented Programming allows you to inject declarative transactional logic without writing any code. It saves a lot of headache.

One caveat: When dealing with some OR/Ms like Hibernate, there is the use of proxy classes. This does pollute things, because there are a few instances where the proxy classes cause problems. In my opinion, that is an implemtation detail that should not escape the service layer. But with Hibernate, it does. Not sure about the .NET implementation.

mrjoltcola
I think that the Service Facade Pattern will help. I'm just trying to define what the contract or interface should look like. I imagine that it will have the standard CRUD methods as well as some for session and transaction management.The top .NET OR/M tools and ADO.NET except Entity Framework seem to make it simple to create such a contract. Yet, my fear is that my project may go with it despite its major flaws. I'd like to push for NHibernate, but leave myself an out just in case Entity Framework is selected.Thanks for the tip about declarative transaction logic.
Genuine