Experienced Devs

3956 readers

1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

[email protected]

Help needed in structuring DatabaseProxy classes following SOLID principles in TypeScript (programming.dev)

submitted 1 year ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

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!

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

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.