Managing multiple persistence mechanisms

Question

I have a set of business objects that potentially can be persisted in different ways, although for any given configuration of the application, only one persistence mechanism will be active. Persistence is handled via interfaces.

The obvious architecture, it seems to me, is to put all the persistence objects for one configuration into one package, and all the objects for a different configuration in another package. But it seems that this plan may end up with a lot of different packages and a package management issue instead. Are there any other good solutions to this problem?

Answer 1

I implemented this at my company by making a reusable repository library.

Basically, I created a repository abstraction with interfaces, that does basic CRUD operations on a passed in object or set of objects. Then I implemented that using various persistence mechanisms. The library can persist any object to XML, JSON, Binary, or SQL. All of those repositories use the same interfaces, so all the code that needs to interact with a repository uses the interfaces, not the concrete implementations. Each implementation lives in it's own library, as do the abstractions, so you only need to distribute abstractions library and whatever implementation your program needs.

There's is nothing to implement in the object model, because it handles generic objects using Reflection (the library is written in C# for .Net).

I also left the repositories open to extension, and in some applications, the default Reflection based stuff is replaced by strongly typed repositories that are more efficient, but are still based on the generic implementations.

Hope that helps.