3 ms·

I agree with you to some degree, but I've built an abstracted data layer in literally every project I've worked on since I learned it was a good practice around

I agree with you to some degree, but I've built an abstracted data layer in literally every project I've worked on since I learned it was a good practice around 20 years ago and I still have yet to be on a project where we actually needed to replace the database. I've moved plenty of databases from on-prem to PaaS, but never switching DB technology itself through an abstraction layer. That's not to say I haven't had to replace data storage, but they were never built as layers and inevitably it happens when moving from mainframes to more modern systems. At this point at least some of my abstraction feels like a waste of time. Maybe when we start moving to Quantum Databases someone will benefit from my extra due diligence from a decade ago.

portsnadaptors 4y ago
I don't think building an abstraction over the data layer is just to make it easier to change your database. The abstraction can define the data access patterns upfront and minimize bespoke data access code. I've spent a lot of hours trying to untangle ORMs and other data access code from business logic. I've found that extending an abstraction to support a new access pattern (that you really need) is much easier.
- rlabrecque 4y ago
  This is one of the bigger discussions I've been involved with lately; and I agree it really comes down to "bespokeness". When you have a 'system' which is 500 LOC, and 10 usages of that system totaling 10 lines each; compared to 10 bespoke implementations of 50-100 LOC each... you get into a spot where the system is battlehardened because of all the users, while the bespoke implementation have issues all over. Then when someone goes to add the 11th use-case of this; they are going to learn from and copy/paste the other version, probably exposing some latent bug in the bespoke version.
scotty79 4y ago
I don't think MS built Entity Framework so that you can switch away from MS SQL Server in any other way than "potentially".

portsnadaptors 4y ago

I don't think building an abstraction over the data layer is just to make it easier to change your database. The abstraction can define the data access patterns upfront and minimize bespoke data access code. I've spent a lot of hours trying to untangle ORMs and other data access code from business logic. I've found that extending an abstraction to support a new access pattern (that you really need) is much easier.

rlabrecque 4y ago
This is one of the bigger discussions I've been involved with lately; and I agree it really comes down to "bespokeness". When you have a 'system' which is 500 LOC, and 10 usages of that system totaling 10 lines each; compared to 10 bespoke implementations of 50-100 LOC each... you get into a spot where the system is battlehardened because of all the users, while the bespoke implementation have issues all over. Then when someone goes to add the 11th use-case of this; they are going to learn from and copy/paste the other version, probably exposing some latent bug in the bespoke version.

scotty79 4y ago

I don't think MS built Entity Framework so that you can switch away from MS SQL Server in any other way than "potentially".