4 ms·

I get lost with all the Microsoft / data modelling terminology, it doesn't have much to do with software I've ever had anything to do with. What is all this "da

I get lost with all the Microsoft / data modelling terminology, it doesn't have much to do with software I've ever had anything to do with. What is all this "data-access layer" abstraction stuff about anyway?

hinkley 9y ago
Your architecture may say exactly all of the qualities of your data are but when it comes to transferring it into and out of a database some of the fidelity is lost. If you're trying to pull the data into a statically typed language (even one that isn't object based) there's an impedance mismatch and you almost have to trick your language into accepting the data. So you hide this indignity in something called an Object Relational Mapper, and the rest of your app just pretends like you have a database that gives you Objects. There are a million flavors of these with their own jargon but it's all the same stuff, and they are all within an order of magnitude of each other on the awfulness scale (which is why I'm not to enthusiastic every time someone comes up with essentially the same thing under a different name. Like, say, Protocol Buffers)
- DonHopkins 9y ago
  Agreed, ORMs all suck because what they're trying to do is essentially sucky. But some are better at sucking than others by orders of magnitude! https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
flukus 9y ago
It's based on the (false) belief that 2 section of the code base accessing/updating the same data will be performing the same function so it should be in one place. This one place is the data access layer and as more exceptions to this belief more and more "business logic" seeps into the data access layer. Then your business layer is anemic because most of the "logic" is moved to the data access layer and it's just an unnecessary pass though from the application layer. Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join. Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost. So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds. And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.
- taneq 9y ago
  This just sounds like the inner-platform effect when applied to database applications. :/
  - flukus 9y ago
    Inner platform effect is different but often teams will do both. The inner platform effect is usually data driven in a "we'll just code this once and generate dynamic code" sort of way. The dream of the inner platform effect is often to automate the production of these 23 useless layers.
- bschwindHN 9y ago
  You just described my previous workplace a little too well...
- incompatible 9y ago
  That's for that. I was thinking maybe it was just different versions of things like ODBC, but that sounds far worse. The database is already supposed to be the "data abstraction layer", and should be perfectly capable of handling multiple requests from different places. I suppose software that just passes around database handle(s) would be a work of barbarism to these people.

hinkley 9y ago

Your architecture may say exactly all of the qualities of your data are but when it comes to transferring it into and out of a database some of the fidelity is lost. If you're trying to pull the data into a statically typed language (even one that isn't object based) there's an impedance mismatch and you almost have to trick your language into accepting the data. So you hide this indignity in something called an Object Relational Mapper, and the rest of your app just pretends like you have a database that gives you Objects. There are a million flavors of these with their own jargon but it's all the same stuff, and they are all within an order of magnitude of each other on the awfulness scale (which is why I'm not to enthusiastic every time someone comes up with essentially the same thing under a different name. Like, say, Protocol Buffers)

DonHopkins 9y ago
Agreed, ORMs all suck because what they're trying to do is essentially sucky. But some are better at sucking than others by orders of magnitude! https://www.sqlalchemy.org/ https://www.sqlalchemy.org/

flukus 9y ago

It's based on the (false) belief that 2 section of the code base accessing/updating the same data will be performing the same function so it should be in one place. This one place is the data access layer and as more exceptions to this belief more and more "business logic" seeps into the data access layer. Then your business layer is anemic because most of the "logic" is moved to the data access layer and it's just an unnecessary pass though from the application layer. Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join. Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost. So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds. And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.

taneq 9y ago
This just sounds like the inner-platform effect when applied to database applications. :/
- flukus 9y ago
  Inner platform effect is different but often teams will do both. The inner platform effect is usually data driven in a "we'll just code this once and generate dynamic code" sort of way. The dream of the inner platform effect is often to automate the production of these 23 useless layers.
bschwindHN 9y ago
You just described my previous workplace a little too well...
incompatible 9y ago
That's for that. I was thinking maybe it was just different versions of things like ODBC, but that sounds far worse. The database is already supposed to be the "data abstraction layer", and should be perfectly capable of handling multiple requests from different places. I suppose software that just passes around database handle(s) would be a work of barbarism to these people.