Some people just dont like the idea of using an ObjectRelationalMapper, they just don't like OOP... and they may even be right (lately after having read about TutorialDee I have been thinking to switch from being an ObjectWeenie, to being a RelationalWeenie) what we need is something more general: a ClientApplicationToDatabaseMapper (or perhaps an AnyLanguageToRelationalMapper??).
- I "like" OOP -- to the extent that "like" is the right word; does a mechanic "like" screwdrivers? -- but I don't like ObjectRelationalMappers. They do not match how I build database-driven applications.
Well the thing is a
ClientApplicationToDatabaseMapper would make it possible to automate stuff like propagating changes from the database to client code, right now, with uncoupled apis like JDBC or ADO.NET, if something changes in the database, the compiler of the client application code doesn't even complain, and the client application programmers need to waste a lot of time doing
GruntWork to adapt the client applications for simple changes like the renaming of a database table, field, or stored procedure, where does that lead to? well, as the amount of grunt work needed to update the database to match the current
UbiquitousLanguage increases, the reluctance to make changes increases too... it is just
GruntWork, but is such an inordinate amount that DBAs and developers just refuse to do it, and the era of workarounds begin, until the the database looks so different from the UbiquitousLanguange
? that any self respecting developer refuses to deal with such a mess
See DatabaseRefactoringTools for context
What this really suggests is the need for general purpose application development languages with integrated database capability (which is where TutorialDee and the like are heading) that do not separate specification of database functionality and client-side functionality into discrete source bases. With a unified source code base, it should be possible to create refactoring IDEs that work over the entire source base, and that invisibly automate (to the degree that this is feasible) deployment of changes into the production installations.
Exactly!