|
|
|
|
|
|
by ldarcyftw
3106 days ago
|
|
|
ORM stands for Object-Relational Mapping (wikipedia). It is just a way to map domain objects to tables. There is no "promotion the use of state" in that definition. It is your choice to start using state in a (mis)designed manner but please don't blame ORMs for that. |
|
|
Many ORMs are built using the Unit of Work / Data Mapping patterns. Such ORM's map your data into a separate domain model and manage this model for you. If your orm has something like an "EntityManager" it has likely implemented this Unit of Work pattern.
A key thing the Unit of Work achieves is to commit changes to the database in a single transaction. You often need to update multiple records in an atomic way within enterprise software.
You might not be faced with such challenges in a simple app, but in monolothic enterprise software it's a core feature of what a good backend server does.
Active Record-based ORMs or query builders aid you only a little in this task; they expose the transaction handling logic so much so that it starts to read as a normal SQL database transaction (and might only be cumbersome to use at worst). Here you, the programmer manages it, similar to a normal SQL transaction.
The Unit-of-Work based ORM is more intelligent. It manages the database transaction for you and figures out any changes that were made to the managed entities. In my experience all Java-built enterprise software (I used Hibernate, EclipseLink and Toplink) are designed this way and make heavy use of it. I've used it with Doctrine in PHP quite a lot, and my guess is C#'s Entity Framework is also built around such concepts. That is a big slice of the ORM market.
Here is where the state comes in; different parts of the applications contribute to creating a single database transaction until flush-time. You as a programmer should know when "flush time" actually happens and understand which entities were marked dirty. That is a lot of hidden state that is managed for you; it is in fact the core of what such ORM's do; managing state until it's ready to be flushed. To make it really advanced, powerful ORMs (the popular enterprisey ones) do a lot of caching too, at different times and at different scopes.
When tackling with such tools the distance to normal SQL becomes very large. I think that is where quite a bit of the hate comes from. It's become very powerful magic.
I've been in places where I had to really understand how this magic works to solve serious performance issues with it. I learned a lot, solving problems that shouldn't have existed in the first place.
I don't like magic. It makes me hide in the corner and cry a little.
My comment was targeted towards the UoW / Data Mapper stuff and much less so to Active Record ORM's.