> I think ORMs fit that bill. For some reason they were (are?) incredibly popular, but I don't think they stood the test of time.
I don't think there is any truth at all to this personal belief. In some domains it's unthinkable to use anything other than the standard ORM. In C# you'd need to be nuts to roll SQL by hand instead of using Entity Framework, and Django speaks for itself.
The only drawback of ORMs is that their promise is that developers don't need to learn the intricacies of SQL and SQL-related design patterns, but in practice developers need to learn the intricacies of SQL, the ORM framework, and the SQL generated by the ORM. Naive developers might believe they are better off reinventing the wheel with ad-hoc SQL stuff, but that's another problem.
I am nuts! I often work on two main C# projects. One uses a data adapter with data table objects. The other, is about to have EntityFramework completely removed. Reduced it to only handling database connections.
Original developers used code first. Looked into the dynamic SQL created by the framework and it was overly complex statements. Replaced with simple hand crafted SQL and Dapper, used just to bind the results to objects. This cut transaction time down dramatically, about 30 seconds down to less than two. I could still cut that down further with batch transactions that are no longer logically grouped.
Simply combining SQL, CSS, and HTML with a custom DSL allows for creating interlinked reporting. Did this on a microC II OS embedded system with SQLite running on hardware with 8mb flash and 64mb RAM. Port the DSL, keep the same table structure, and the same reports can be used in a new environment with new hardware or different database backend.
EntityFramework might be useful in some places. I have yet to work in a domain where it is.
I don't think there is any truth at all to this personal belief. In some domains it's unthinkable to use anything other than the standard ORM. In C# you'd need to be nuts to roll SQL by hand instead of using Entity Framework, and Django speaks for itself.
The only drawback of ORMs is that their promise is that developers don't need to learn the intricacies of SQL and SQL-related design patterns, but in practice developers need to learn the intricacies of SQL, the ORM framework, and the SQL generated by the ORM. Naive developers might believe they are better off reinventing the wheel with ad-hoc SQL stuff, but that's another problem.