Is ORM fit for complex projects? [closed]

Question

I've not started the ORM trip yet,

because I'm not sure how it works when the project becomes very complex.

What's your opinion or experience?

Answer 1

This question is a difficult one to answer sometimes. You may have heard of the Object-Relational Impedance Mismatch before; that is the issue that ORM tools attempt to solve, but it is fraught with problems. It is one of those situations where you can solve 90% of the problem in a very short time, but every additional 1% from there on up seems to increase exponentially in complexity because of all the dependencies.

An ORM framework is an abstraction, and becomes a leaky abstraction at several points:

• Complex queries/scripts involving concepts like UDTs, CTEs, query hints, temporary tables, windowing functions, etc.

• Performance-optimized queries. As Quassnoi mentioned in his answer, ORMs are getting better at this but frequently generate sub-optimal queries, and sometimes the effect is extremely noticeable.

• Transaction management - the Unit-of-Work pattern can only get you so far when you have to deal with large batch updates.

• Cross-database or cross-server actions. There are workarounds, but they are just that - workarounds. No ORM I've seen really handles this well.

• Multiple-table inheritance - this is the only form of inheritance that is actually normalized, and it is really not that hard to manage using pure SQL and manual mapping, but O/R mappers are lousy at it. For many of us, single-table inheritance is not an acceptable alternative.

Those are some of many areas where O/R mappers seem to fail us. Having said that, this does not mean that O/R Mappers are not "fit" for large projects.

In my opinion, ORM in general and O/R Mappers specifically are almost vital for large projects. They save enormous amounts of effort and can help you get an application out the door in a fraction of the time it would have taken you otherwise. They just do not solve the whole problem. You have to be prepared to profile your application to see what the ORM is really doing, and you have to be prepared to drop back down to pure SQL when the situation calls for it (i.e. in several of the situations above).

Some frameworks, such as Linq to SQL, expect you to do this and give you ready-made facilities for executing commands or stored procedures on the same connection and in the same transaction used for the mapper's "regular" duties. L2S is not the only framework that lets you do this, but several are more restrictive, and you end up jumping through many hoops to get what you need. When choosing an ORM, I think that the ability to bypass the abstraction is an important consideration, at least today.

I think the best answer to this question is: Yes, they are fit for large projects, as long as you do not rely exclusively on them. Know the limits of your ORM tool of choice, use it as a time-saver in the 90% of instances when you can, and make sure you and your team understand what's really going on under the hood for those instances when the abstraction leaks.

Answer 2

ORM. by defintion, is object-relational mapping.

This means that you should transform the data stored in a relational database into the objects usable by an object-oriented programming language.

The objects may supply some methods that may involve data processing and searching for the other objects.

This is where the problems begin.

The data processing may be implemented on the ORM side (which means loading the data from the database, applying the object wraparound and implementing the methods on the programming language you use), or on the database side (when the data processing commands are issued as a query to the database).

Compare this:

MyAccount->Transactions()->GetLast()

This can be implemented in two ways:

SELECT  *
FROM    Accounts
WHERE   user_id = @me

into $MyAccount

, then

SELECT  *
FROM    Transactions
WHERE   account_id = @myaccount

into a client-side array @Transactions

, then $Transactions[-1] to get the last.

This is inefficient way, and you'll notice it as you get more data.

Alternatively, a smart ORM can convert it into this:

SELECT  TOP 1 Transactions.*
FROM    Accounts
JOIN    Transactions
ON      Transactions.Account = Accounts.id
WHERE   Accounts.UserID = @me
ORDER BY
        Transactions.Date DESC

, but it has to be a really smart ORM.

So the answer to the question "whether to use an ORM or not" is the answer to the question "will my ORM allow me to issue set-based operations to the database should the need arise"?

Answer 3

This is subjective. My answer is specifically about automated ORM Tools.

I have a philosophical objection to ORM Tools for the following reasons:
1- A table is not and should not necessarily be a one-to-one mapping to a business object.
2- Base CRUD/Business Object code is boring to write, but it's critical to your application. I'd rather be in control and have knowledge of it. (a little NIH syndrome)
3- A new developer coming in is going to have an easier time learning a traditional object model versus whatever bizarre syntax is created by the ORM tool.