How to implement the repository pattern for an app that will change its database from sql to nosql on in couple of years?

Question

I have been reading a lot about repository implementation. I am confused about which way to implement it for a project I am sure would change its data layer methods because of db migration from MS Sql Server to NoSQL in a couple of years.

Imp #1

• Implement Rep layer as a completely separate layer. This will have its own interface and conversion methods here. This rep layer has a dependency on DAL and in turn BLL will have a dependency on this layer

Imp#2

• Implement Repository not as a separate layer but have its interfaces in Business Logic Layer and the methods in DAL.

I am leaning more towards imp #1 since it looks cleaner. However some explanations of experts I have read use imp#2. I think there must be a clear reason to use one over another according to the situation. I would ideally want our switch to a different database be as painless as possible.

Answer 1

The main reason you would have the interfaces for your repositories in your BLL is to avoid having hard references to the separate DAL but instead have your changing DAL reference the stable BLL.

To be able to swap out implementations without changing the stable BLL

On the internet this might not be the main reason in general, but this would be a compelling reason for me to prefer option 2 in your situation.

Let's assume that you are using a DI (dependency injection) container. If you configure this using a configuration file, for example, you would tell the container that the implementations for the repository-interfaces in the BLL can be found in the DAL.Sql project. Once you switch over to a NoSQL solution you would create the DAL.NoSQL project, deploy it and change the DI container configuration to resolve the implementations of the repository from the new project. Your new DAL depends on the stable BLL that does not need to change.

However, if you go with option 1, you might not be able to hot-swap the DAL project. If you use .NET for example you could run into issues where the BLL project depends on a certain version of the DAL dll and you would not be able to swap out the DAL without changing the BLL as well.

Because the repository interface is part of the BLL

A repository is merely a gateway that defines how your application will retrieve data. In that sense it is as much a part of the business logic as your domain objects. The concrete implementations can change, but the interfaces themselves are part of your business logic.

Because it isolates the BLL

Having the interfaces and implementations in the DAL means bringing all of the DAL into the BLL. There is nothing preventing developers from using objects from the DAL project in ways that they shouldn't be used. Having the DAL depend on the BLL means the BLL can only contain the interfaces that it needs.

To avoid a separate project with the domain objects

Your DAL and BLL both depend on your domain objects. If your BLL has a class that uses a repository and a domain object, you cannot put your repository interfaces into the DAL as that creates a circular reference (BLL needs interface for repository in DAL, DAL needs domain objects in BLL). So you would have to split the BLL and the domain objects into two projects so your BLL can reference the domain and the DAL and the DAL can also reference the domain.

Answer 2

Sticking to option 1 will allow you to change the least amount of things when you switch from one database to another, thus the change should have the least impact on your application since only the files concerned with the database will need to be changed.

The business layer and any other layer which does not deal with the database should not care, nor know any implementation details. Thus, when you mention that ...and in turn BLL will have a dependency on this layer I am assuming that you would have a series of interfaces, such as IUserRepository or something like that which will define methods such as GetUserByName(string name), etc.

Layers on top of the repository will then consume these interfaces to suit their data needs, this would allow the business layer to know what the repository layer provides, but it will not include any implementation details. Thus, when you make the change, as far as the business layer is concerned, nothing is changed (assuming that you do not make any changes in the functionality provided by the repository layer).

Answer 3

@JDT's answer is correct. Imp#2 is the better option. The dependency inversion principle (DIP) as described by Robert C. Martin implicitly demands that if you have two modules A and Band an interface IB which is implemented by B and injected into A the definition of IB should be within the context of A.

Actually it's the second clause of the DIP that demands this:

Abstractions should not depend on details. Details should depend on abstractions.

In the case of BLL and DAL the BLL is the high level module und the DAL is the low level module. If the abstraction (the interfaces for the repositories e.g.) would be definied within the DAL then the abstraction (the interfaces) would depend on the details (the implementation). If the details change (e.g. when you swith to the NoSQL DB implementation) the abstraction/interfaces will also change and the high level module (the BLL) will have to be changed as well. And this is not desired. So clearly the answer to your question is Option #2.

Looking briefly for some sources to back this up I found this on Wikipedia on the DIP:

The interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's library. The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship.