Earlier quoted context omitted.
> and still be using an enormous amount of automation to deal with the database drivers and moving data between your objects and rows I've found I would generally only need the handling of database drivers and query building since I'm already writing a validation layer and to add data marshalling to that is pretty trivial. Likewise practicing YAGNI, what is the chances I need multiple database drivers for different d…
> I would argue to start with writing the basic SQL queries and adding an ORM later when you know you actually need it. I think you missed the point of the parent comment, which is that ORM's are not about writing SQL queries (although they do that). But ORMs are about moving data around, transforming it from rows and columns into meaningful objects in the project's language and data model. As the parent comment sugg…
I made my point about this but will repeat, I am generally writing validation for this, adding the code that converts this into known types isn't significantly more work, if I was never writing the validation this point would make sense. Also the ORM the parent comment is an author of doesn't do this, it generates a class with a ton of ancillary ORM specific functions that I don't care for and many ORMs do that.
I don't even agree with what the article states, the article is effectively creating a custom ORM, I'm saying write a function that converts the data from your database driver to the type of thing you want, write a function that validates that data, those two can be 1 function for simple data but likely will be 1 function which is a composition of other functions.
When you get to the point where that is tedious you now likely have a good idea of what you want in an ORM and are significantly better equipped to make an informed decision for your specific project, you might find you end up only wanting a query builder.
Regarding abstraction over database drivers, well how often do you need an abstraction over database drivers, are you really using two or more different databases in a single project?
My ideal workflow is: 1. Query exactly what I want 2. Make it valid data in the form I want
That valid data shouldn't have a ton of extra stuff attached to it, I want plain old data that is validated and the correct type.
Why would I add a dependency that is complex before I can make an informed decision that I would even need it?