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

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... ).