decino / viewer-submissions-form

Webapp for viewers to submit Doom levels to decino's YouTube channel.
MIT License
7 stars 4 forks source link

move to repo and DAO pattern #9

Closed VictoriqueMoe closed 1 year ago

VictoriqueMoe commented 1 year ago

I hated the fact that i use TypeORM repos everywhere without a clear standrd architecture in applying a DAO layer and repo layer to services.

I dencided to change this.

the new architecture is as followes:

Controller -> Service -> Repo -> DAO

VictoriqueMoe commented 1 year ago

Mostly looks good. I made a few comments that may need to be addressed, but not much.

That being said, I do have one more fundamental question and that is, what does the project gain from doing this? From what I can tell, this just abstracts out some of the data logic from the various services into a separate data layer. I mean, that's nice from an architecture standpoint I guess. But it seems a bit of overkill for such a small app, plus opens up the project up to a new round of unnecessary bugs if it was working as-is.

Why? Becsuse the way I was doing it made me cringe.

This doesn't introduce bugs. This fixes bugs.

Before transactions where not normalised, in fact. They never existed becsuse I could not create transactions across multiple repos unless I wanted to wire them in and create pointless coupling.

This ain't overkill, it's standard microservice architecture.

You have a controller layer, then a service layer. Then a repo and dao layer. I only omitted the last 2 becsuse... Well... I was lazy.

Now with this abstraction, I have managed to totally uniform the interfaces with interacting with the dB, keeping the service layer to business logic only and not having to manage transactions and databases.

It's far better, and much easier to use, you can see from the vast amount of code I have deleted from the service. And now I can use more cascading updates and deletes.

This change also speeds up the database access becsuse less queries and not having to get a repo every single time.

The way it was done before was poor, and lazy. This just keeps it up with standard architecture as it should be done from the start. Even a tiny tiny microservice would have these 4 fundamental layers.

It also allowes me to sleep at night knowing I've done it right :)

nakedmcse commented 1 year ago

Code reads well and I see no obvious defects. The implementation of the repository architecture is a good choice in the long run.