Hi everyone,
In a project involving Firebase and object types like Tickets, Schedules, and Timers, I want to structure my classes such that switching databases (potentially to MySQL) wouldn’t require a complete rewrite.
Approach 1:
- A DatabaseProxy interface with generic methods (e.g., createTicket, createTimer, etc.)
- A FirebaseProxy class implementing the interface, with methods for each object type (e.g., createTicket, createTimer, etc.)
- Manager classes for Tickets, Schedules, and Timers, that primarily use the FirebaseProxy for operations. This provides flexibility for processing input/output, but most of the time the manager classes will just be calling methods on the Proxy directly.
Approach 2:
- A DatabaseProxy interface with the most basic CRUD methods (create, read, update, delete).
- A FirebaseProxy class implementing the interface.
- Manager classes for Tickets, Schedules, and Timers, calling FirebaseProxy with parameters like update(collection, ticket) and implementing createTimer, createTicket, etc.
I like the second approach in theory, but what I’m worried about is whether the separation is too low level. What happens if the database I switch to changes schema such that taking in an object and a collection name isn’t good enough anymore? For example, will there be concerns if I switch between Vector, NoSQL, and SQL?
Any opinions are appreciated!
I would go with the second approach. Quickly thinking about the two suggestions trying to figure out where they could go south I can’t come up with anything as long as the schema remains as simple as suggested in the post.
The difference between the two abstractions you suggest is not huge and the simpler one - well - is simpler to understand. If you don’t see a reason the underlying DB should change and completely change the paradigm it’s built on you should be fine with whichever.