Skip Navigation
Experienced Devs @programming.dev JokersPistol @programming.dev

Help needed in structuring DatabaseProxy classes following SOLID principles in TypeScript

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!

4

You're viewing a single thread.

4 comments

  • Hello. Appreciate your question. I think that this is a good use case for the Repository Pattern.

    Image describing the Repository Pattern

    In your case, this might look something like this:

    • TicketRepository, ScheduleRepository and TimerRepository interfaces which have their functions like create(), read(), update(), delete(), complexQueryByManyParams() etc. All your domain code should expect and operate on these interfaces.
    • FirebaseTicketStore, FirebaseScheduleStore, FirebaseTimerStore classes which implement the respective interfaces. All your logic that relates to Firebase should be encapsulated here.
    • You can later safely do things like swap out a FirebaseTicketStore with a MysqlTicketStore

    You can consult the Design Patterns / Gang of Four book for more details

    Off topic, but personally I don't feel you should worry too much about having to change the database in the future. I have rarely seen it happen in my career.