Does my repository have too much logic?

Question

I have a legacy database that my new application has to interact with. The old database is over-normalized and poorly designed in general. For instance, one object in my domain represents five tables in the database. I want to keep my domain layer free of artifacts from the legacy database. What pattern should I use here?

At first glance, I think about Repository Pattern. I would pass my object to the repository and let it handle splitting the data up into the five tables. However, it was suggested that all the mapping that must be done adds too much logic to the repository. So, it Repository a bad choice here? Should I use Repository with another pattern (like Adapter)? Or is Repository the right choice in this situation?

Answer 1

Might the Gateway pattern help? Create a Gateway to the old database. Place all the conversion logic in the Gateway.

Answer 2

I think the Data Mapper pattern is what you're after. Incidentally, you can probably gain quite a few insights about hand-rolling your data access in this series of posts by Davy Brion.

I'm interested though, why not look towards something like NHibernate instead of trying to do all the dirty work yourself?

Answer 3

The Repository pattern is appropriate here, but using Data Mapper, as suggested by DanP, will aid in adhering to the Single Responsibility Principle. ORMs such as NHibernate and Entity Framework generally facilitate the role of the Data Mapper, but it can be appropriate to implement this logic yourself if your data store isn't conducive to using an ORM.

Jeff Morris provides a pretty good example of using Data Mapper within the context of the Repository pattern here.

For the record though, the job of an ORM is to bridge the object-relational impedance mismatch. A relational database schema will often differ in structure from the domain model. Your database may very well be poorly designed for other reasons, but the lack of a one to one relationship between entities and tables shouldn't by itself be understood as an indicator of poor design. Viewed from a DDD perspective, where the database is considered the persistence store for an application domain, the database may have been normalized appropriately for the original domain it was written to serve.