How can I gradually transition to NHibernate persistence logic from existing ADO.NET persistence logic?

Question

How can I map properties of a type with no NHibernate mapping? How should I manage the dependencies on old data access logic during the transition?

The application uses ADO.NET to invoke sprocs for nearly every database operation. Some of these sprocs also contain a fair amount of domain logic. The data access logic for each domain entity resides in the domain class itself. ie, there is no decoupling between domain logic and data access logic.

I'm looking to accomplish the following:

• decouple the domain logic from the data access logic
• make the domain model persistence ignorant
• implement the transition to NHibernate gradually across releases, refactoring individual portions of the DAL (if you can call it that) at a time

Here's my approach for transitioning a single class to NHibernate persistence

1. create a mapping for the domain class
2. create a repository for the domain class (basic CRUD operations inherited from a generic base repository)
3. create a method in the repository for each sproc used by the old DAL (doing some refactoring along the way to pull out the domain logic)
4. modify consumers to use the repository rather than the data access logic in the class itself
5. remove the old data access logic and the sprocs

The issues I have are with #1 and #4.

(#1) How can I map properties of a type with no NHibernate mapping?

Consider a Person class with an Address property (Address being a domain object without an NH mapping and Person being the class I'm mapping). How can I include Address in the Person mapping without creating an entire mapping for Address?

(#4) How should I manage the dependencies on old data access logic during the transition?

Classes in the domain model utilize the old data access logic that I'm looking to remove. Consider an Order class with a CustomerId property. When the Order needs info on the Customer it invokes the ADO.NET data access logic that resides in the Customer class. What options are there other than maintaining the old data access logic until the dependent classes are mapped themselves?

Answer 1

I would approach it like this:

1. Refactor and move the data access logic out of the domain classes into a data layer.
2. Refactor and move the domain logic out of the sprocs into a data layer. (This step is optional, but doing it will definitely make the transition smoother and easier.)
3. You don't need a repository, but you can certainly create one if you want.
4. Create a NHibernate mapping for every domain class (there are tools that do this).
5. Create a NHibernate oriented data access API that slowly replaces the sproc data layer.

Steps 1 & 2 are the hardest part as it sounds like you have tight coupling that ideally never would have happened. Neither of these first two steps involve NHibernate at all. You are strictly moving to a more maintainable architecture before trying to swap out your data layer.

While it may be possible to create NHibernate mappings one by one and utilize them without the full object graph being available, that seems like asking for unnecessary pain. You need to proceed very cautiously if you choose that path and I just wouldn't recommend it. To do so, you may leave a foreign key mapped as a plain int/guid instead of as a relation to another domain class, but you have to be very careful you don't corrupt your data by half committing to NHibernate in that way. Automated unit/integration tests are your friend.

Swapping out a data layer is hard. It is easier if you have a solid lowest common denominator data layer architecture, but I wouldn't actually recommend creating an architecture using a lowest common denominator approach. Loose coupling is good, but you can go too far.