4 ms·
Following this advice too closely and your application logic starts leaking into your data layer. One simple example is when you need to make atomic changes to
by jakelazaroff 3y ago
Following this advice too closely and your application logic starts leaking into your data layer.
One simple example is when you need to make atomic changes to two different types of entities. In the data layer, this is usually trivial — just run two queries within a transaction — but you need to expose a function that boils down to `updateBothAandB`. Rinse and repeat enough times and your data layer is a soup of business logic.
- mvdtnz 3y agoThere are patterns to resolve this. Depending how you structure your DAL, your data access classes can provide transaction handles. It's a data access layer, you don't need to abstract away the fact that you're dealing with a database.
- paulryanrogers 3y agoIME young businesses evolve so quickly too much abstraction is a higher risk that some bleeding among DAL and business rules.
- edgyquant 3y agoHow is this not just a hand rolled ORM?
- JohnBooty 3y agoAn ORM is a specific kind of data layer. It is general-purpose, and as the name suggests, it is an Object-Relational Mapper whose primary purpose is to map relations to objects and vice-versa. So no, bespoke data access layer code is not an ORM.
- jakelazaroff 3y agoI mean, yeah, but the patterns all look like the thing you said you don’t accept in your own applications: “something like a query builder that allows different parts of the application to work together to lazily compose queries”.
- jupp0r 3y agoExactly, in my opinion, separating your business logic from your data access layer completely is futile. You will need to either have business logic in your data access layer or fine grained query controls (when to add a filter clause, when to execute a query, what should go into a transaction, etc) in your business logic for performance reasons. This is OK, it's incidental complexity.