Pfthb

There is a pattern of making a DAO interface before DAO implementation. I googled the advantages of this pattern and one striking point was to support multiple databases.

Now, what i could understand is that multiple databases here means different database engines rather than multiple datasources. Obviously multiple datasources should not have affect on how DAO implementations are made out of DAO interface.

My question is what can be the situations where we may need to support multiple database engines catering the same data? Also if such need arises, how will the REST endpoints be managed to support different databases?

Will they be like for e.g. /db1/courses/, /db2/courses ? Do correct me if i have made any wrong assumption or statement in this question.

I came across this situation where I had to check two DBs and get the data. The other DB was a back up one.

So this was the flow.

 RestController --> Service --> DBService 
 --> DB1Repository --> Connect to DB1
 --> DB2Repository --> Connect to DB2

We can design as we want, all it matters at the end is that we follow SOLID principles.
Basically the high level components should not depend on the low level components, but both should depend on the abstractions.

I just wanted to add my answer to this about beginning Spring development. This is one of the things that initially will not make sense at first. You will end up asking yourself:

• There will be only 1 database, so this doesn't make sense why do it?


• Why would I define an interface when there will only ever be 1 implementation?

But really neither of these are really why you do this. But it is the convention and pattern and this style is just what people are use to and you will like it better overtime. There are some other reasons too:

• Spring Data - this is an alternative to using an entity manager, whereby you only define interfaces and Spring will actually create beans which implement your repository functionality for you.


• Design - ensuring you define an interface will help keep your repository a repository.


• Easier Mocking - although arguably you can still do this in Spring without needing to define an interface it is still a bit cleaner when you want to replace the implementation with another.

But really it is just the Spring way, people will find it easier to understand your code if you do this.

Ill pop in here to describe a real world example.

We recently wanted to change out a large production database (Oracle) to a different one (SQL Server).

For different areas of the database, we had different DAO interfaces and implementations. For example, CustomerDAO, AccountsDAO, etc.

For each interace (like CustomerDAO) we had an implementation (CustomerDAOImplOracle).

It was relatively straight forward for us to write SQL Server versions of the DAO's (the SQL syntax and jdbc libraries were of course different) and swap them over with minimal changes to our business logic (the services which use the DAO's).

So, CustomerDAOImplOracle was reimplemented at CustomerDAOImplSQLServer. And so on...

What we learn:

1. Interfaces provide good abstractiuon and allow for multiple implementations


2. The DAO layer allows us to "switch out" the database (or its client libraries) if necessary


3. Hiding implementation details of the database from the business logic reduces coupling and complexity