Is ORM fit for complex projects? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

I've not started the ORM trip yet,

because I'm not sure how it wor开发者_开发百科ks when the project becomes very complex.

What's your opinion or experience?

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.

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"?

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.

You don't mention what platform you are using, but if I wanted to read a record from a database in .NET without using an ORM, I would have to:

Read a Connection String
Open a Database Connection
Open a Command object against the connection
Read my Record (by execute a SQL statement against the Command object)
Transform that Record to an object in my language of choice
Close my query
Close my connection

Sound complicated? An ORM does all of the same things automatically under the covers, and I only need a few lines of code. In addition, because the ORM has knowledge of your data model, it can sometimes perform optimizations such as caching and lazy loading.

When project becomes more complex it is even better, because it let's keep everything at the same level of abstraction, rather than jumping from objects to SQL. We once have written our own layer in paralell to developing the application (because we couldn't use any traditional ORM), and the more powerful it became, the easier managing application become.

Performance concerns are you usually overrated. It's usually in different place, then you would expect. We had some badass abstraction layer written in Python, and it working great. What sucked, was url library, which we had to rewrite in C. Really, you can always optimize queries, that are most important at the end, writing SQL by hand at the moment, when you see, that performance needs it. But in most times - you won't have to.

In my opinion ORM built for big projects, to minimize effort and development time.

But if you are developing an application which needs very high speed data access code, you need to avoid ORMs as you can because ORMs add a new layer in your application

ORMs are ideal for large projects because they provide a layer of protection from changes on the database side, and speed up the process of adding new features. If performance becomes an issue, you can use a different method to get to your data at the query where you encounter a bottleneck, rather than hand-optimizing every query in the application.

ORM's are cool if you want to pump out web app's quickly to do customer development and see if people actually use your product.

http://www.youtube.com/watch?v=uFLRc6y_O3s

The very last topic that Josh Berkus discusses is "Runaway ORM's". Check it out at 37:20.