2 ms·
> If you use both, now you have to deal with integrating them both into your code in some semi-consistent way I have no idea what you mean by this. What does i
by Capricorn2481 3y ago
> If you use both, now you have to deal with integrating them both into your code in some semi-consistent way
I have no idea what you mean by this. What does it matter to my business logic whether a repository function got data from an ORM or from Raw SQL? In either case, I would return the same kind of data.
The edge of your application, where side-effectful stuff like DB queries sits, is exactly where you don't need to do anything consistently. You're always fetching random stuff. At some point, you need to turn that into a format that your code understands. That doesn't change if you decide to only use raw SQL.
- ragnese 3y agoI apologize for not being clear, but it was somewhat intentional because I didn't want to get dragged down into arguing about a specific ORM if I made too concrete of an example. What I'm thinking of is situations where you might have multiple queries/statements that need to be done together within a transaction. Depending on exactly what your ORM's API is like, it may or may not be easy to run a piece of ORM-using code with a piece of Raw-SQL-using code inside the same transaction at that "application edge". It can also be especially tricky if the ORM in question is one of those real heavyweight solutions that does caching, "dirty" checks for updates, etc. You have to be careful if you ever mix Raw-SQL functions with ORM functions in a use-case. So, those are the kinds of things I mean. This probably isn't much of an issue for more lightweight, simple, ORMs, but it's an issue I've run into with at least one of the big, heavyweight, ones.
- Capricorn2481 3y agoGot it, thanks