5 ms·

The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that ret

The code that uses arrays instead of objects is worse to support because you don't know what those arrays contain and cannot type-hint them. Functions that return arrays usually don't document their structure. And even if they do, the documentation might be outdated. So you either have to spend a lot of time tracing where do those arrays come from and where they go to or risk breaking something. This approach works well only with tiny applications written by a single person. Once the app grows larger it will get hard to support. ORM have their disadvantages but you have to learn them thoroughly including how they are made internally. They are not some magic tools that "just work". But in a large application you have to use objects and therefore ORM. ORMs usually have some form of SQL-like syntax, for example Doctrine has DQL.

throwanem 10y ago
So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha. Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your perspective comes from heavy, perhaps exclusive, experience with such languages. Certainly I'm not sure where else one might get the idea that the ORMless style "works well only with tiny applications written by a single person", or "in a large application you have to use objects and therefore ORM". That said, what I've seen of the pervasively object-oriented model and how it's used in general leaves me with severe doubts about its value - it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. You end up with your application state torn into tiny shreds and scattered to the wind. Perhaps that's easy to reason about for some. I have not found it so.
- codedokode 10y ago
  ORM doesn't save you from understanding how code works. It is not a tool to avoid learning SQL or UnitOfWork pattern. But it has other advantages: you can use objects for your models, you can use lazy loading and relations between models, you don't have to save modified entities explicitly. So it helps to avoid writing low level code for saving and loading data from a database. You don't have to write routine methods like "get something by id", "get tags for post" or "update a field in a table". > it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. That might be over-engineering. OOP doesn't require you to use every single pattern from a book or build multilevel hierarchies of abstract classes. Abstract classes and interfaces might be necessary when you try to build reusable libraries or components but you don't have to use them inside a monolith application. But you need to learn things like single responsibility principle so you can divide complex tasks into smaller parts. You have to remember that your code will be maintained by other people so it needs to be easy to understand without searching through all the codebase and hard to break. And whatever approach you use when you have an application with large codebase written by many people it will be complicated anyway. OOP can help you to organize this code. > ORM in a typed language PHP is not statically typed language but you can use type hints for functions. So if you have an argument with a class name specified you can quickly look up what properties and methods the object has (and your IDE will suggest autocomplete options). And you cannot have any such information if the argument is an array. I used to work with large applications written using "SQL and arrays" approach and they were bad. I had to spend most time figuring out what kind of array is passed to some function and how it is used to display something on a page. And it is hard to check if you don't break something by removing or changing a single element in that array. That is why I think this approach is not scalable beyond small applications written by a single developer. It has no relation to whether mixed arrays are allowed in a language or not. You can get same kind of code if you misuse collections in Java or C# or maybe Go. You can look at Drupal if you need an example of complex open source application with those problems. It passes a lot of arrays around that are not even documented anywhere. And as an example of OOP application you can see Magento. It is large and very customizable so they had to use different abstractions.
  - joesmo 10y ago
    Magento is a horrible app with one of the worst ORMs in existence. You've clearly never used it if you're touting it as an example of what to do. Because Magento is a laundry list of what not to do. ORM, EAV, XML config. Drupal may not be the greatest app out there, but it is leaps and bounds ahead of Magento. In fact, it's hard to find anything as shitty as Magento.
joesmo 10y ago
Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See: http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.
- codedokode 10y ago
  I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities). The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around. > http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them. He writes: > There is no User but it’s very likely there is SignupUser. And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them. I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them. I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects. The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code). I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there. I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQL-to-MongoDB2.jpg https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).

throwanem 10y ago

So not using an ORM is bad because you then need to understand the code in detail, but even though using an ORM is good, you then need to understand the code in detail. Gotcha. Less flippantly, I've never actually used an ORM in a typed language, and I suppose it's plausible the concept offers benefits there which aren't available elsewhere, especially if arrays of mixed type aren't permissible. It sounds like your perspective comes from heavy, perhaps exclusive, experience with such languages. Certainly I'm not sure where else one might get the idea that the ORMless style "works well only with tiny applications written by a single person", or "in a large application you have to use objects and therefore ORM". That said, what I've seen of the pervasively object-oriented model and how it's used in general leaves me with severe doubts about its value - it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. You end up with your application state torn into tiny shreds and scattered to the wind. Perhaps that's easy to reason about for some. I have not found it so.

codedokode 10y ago
ORM doesn't save you from understanding how code works. It is not a tool to avoid learning SQL or UnitOfWork pattern. But it has other advantages: you can use objects for your models, you can use lazy loading and relations between models, you don't have to save modified entities explicitly. So it helps to avoid writing low level code for saving and loading data from a database. You don't have to write routine methods like "get something by id", "get tags for post" or "update a field in a table". > it encourages the promiscuous mingling of code and behavior, and makes it very difficult to produce code which can be understood without reference to complex interactions among many instances of many classes. That might be over-engineering. OOP doesn't require you to use every single pattern from a book or build multilevel hierarchies of abstract classes. Abstract classes and interfaces might be necessary when you try to build reusable libraries or components but you don't have to use them inside a monolith application. But you need to learn things like single responsibility principle so you can divide complex tasks into smaller parts. You have to remember that your code will be maintained by other people so it needs to be easy to understand without searching through all the codebase and hard to break. And whatever approach you use when you have an application with large codebase written by many people it will be complicated anyway. OOP can help you to organize this code. > ORM in a typed language PHP is not statically typed language but you can use type hints for functions. So if you have an argument with a class name specified you can quickly look up what properties and methods the object has (and your IDE will suggest autocomplete options). And you cannot have any such information if the argument is an array. I used to work with large applications written using "SQL and arrays" approach and they were bad. I had to spend most time figuring out what kind of array is passed to some function and how it is used to display something on a page. And it is hard to check if you don't break something by removing or changing a single element in that array. That is why I think this approach is not scalable beyond small applications written by a single developer. It has no relation to whether mixed arrays are allowed in a language or not. You can get same kind of code if you misuse collections in Java or C# or maybe Go. You can look at Drupal if you need an example of complex open source application with those problems. It passes a lot of arrays around that are not even documented anywhere. And as an example of OOP application you can see Magento. It is large and very customizable so they had to use different abstractions.
- joesmo 10y ago
  Magento is a horrible app with one of the worst ORMs in existence. You've clearly never used it if you're touting it as an example of what to do. Because Magento is a laundry list of what not to do. ORM, EAV, XML config. Drupal may not be the greatest app out there, but it is leaps and bounds ahead of Magento. In fact, it's hard to find anything as shitty as Magento.

joesmo 10y ago

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See: http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.

codedokode 10y ago
I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities). The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around. > http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them. He writes: > There is no User but it’s very likely there is SignupUser. And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them. I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them. I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects. The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code). I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there. I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQL-to-MongoDB2.jpg https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).