Reputation:
I had to write a data access layer in a certain java project to support both nosql and SQL db severs.
To use it you need to configure which db server you're using and use the business logic layer which uses the DAL behind the scenes.
I wrote a basic DAO interface for the basic operations such as remove update and so on.
For the BL layer I wrote abstract classes using the basic interface which would receive it from a DAO factory. You needed to get those classes from another factory handling the BL instances.
Things were getting more complicated and the code turned to boilerplate when I needed more complex queries for the db which each one needed to be implemented separately and then I needed to check and cast the type of the DAO to use the methods hidden by the basic interface. This resulted in many classes for only one model object.
TL;DR I need a simple and scalable way to handle objects with a single API when the db type isn't known until run-time.
My question is whether there is better way to handle this problem? Maybe some design pattern I'm not familiar of which could be nice.
Thank you!
Upvotes: 0
Views: 1644
Reputation: 1444
Creating an abstract data layer is not the aim. The aim should be to create an abstraction for the business layer to interact with. There are some more Enterprise Integration Patterns together with the Query Object from the Gang of Four which can help formalise an approach to your problem.
CQS (Command/query seperation)
CQRS (Command/Query Segregation Principle)
Upvotes: 1