Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs.

I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM.

I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.

  var results = db.myTable
    .where(x => x.value > 6)
    .where(mySpecialConditionalLogicFunction)
    .select(x => { 
      thing = x.relation.relation.relation.value, 
      thingList2 = x.relation.relations
        .groupby(y => y.value)
        .select(g => g.count)
        .orderby(y => y.value)
        .take(5),
      thing3 = x.relations
        .where(z => z.relation1.value < z.relation2.value)
        .select(z => z.relation.value)
        .max(),
      thing4 = myReusableSelectDTOfunction,
      etc..

However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.

The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.

Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.

The SQL would be

  select w.value
  from x
  join y on y.relation=x.relation
  join z on z.relation=y.relation
  join w on w.relation=z.relation

In addition compiling will validate the ORM code generates valid SQL. On the other hand compiling will not validate a SQL string.

'Custom functions' are just larger versions of the anonymous functions in my example. Very easy for other developers to go to the reference and understand.

Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.

I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.

Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.

Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.

You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.

I do recommend reflecting on things as not knowing everything goes both ways.

Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity).

Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php.

My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.

I think we’d need to know a lot more about each other’s projects and experiences to continue as this debate has become a bunch of generalizations.