Applications communicate with the db through some sort of layers (Repository or Data Access Object for example). Currently we don't do that, and we communicate directly with the db throughout the application. Well, mainly in the queries-folder, but files inside it also contain business logic, which kind of undermines the idea of such design pattern.
For a refactor, we could keep the queries-directory, but separate all non-query code from the pure-query code. Non-query code could be moved to some logic-layer.
In addition: in some files we use the drizzle-orm query builder, and in other files we use raw sql. Is there a reason? Are the raw-sql queries too complex to write in the drizzle builder? Would it be worth it to standardize this (so solely use raw sql, or the builder, not both)
Originally posted by @stijn-vh in #13 (comment)
Applications communicate with the db through some sort of layers (Repository or Data Access Object for example). Currently we don't do that, and we communicate directly with the db throughout the application. Well, mainly in the queries-folder, but files inside it also contain business logic, which kind of undermines the idea of such design pattern.
For a refactor, we could keep the queries-directory, but separate all non-query code from the pure-query code. Non-query code could be moved to some logic-layer.
In addition: in some files we use the drizzle-orm query builder, and in other files we use raw sql. Is there a reason? Are the raw-sql queries too complex to write in the drizzle builder? Would it be worth it to standardize this (so solely use raw sql, or the builder, not both)
Originally posted by @stijn-vh in #13 (comment)