Best arguments for/against introducing ORM technology into a companies dev process [closed]

Question

I have started using ORM technology in the last few years. My first exposure was NHibernate. I then moved onto Linq 2 Sql, and Entity Framework.

The issue I have however is, there are some organisations where I have found strong opposition to introducing ORM tools.

They usually have a number of reasons:

• they have a lot of built up SQL skills in the team, and are worried about the underlying SQL that ORM's generate.
• they have DBA's who like to be able to see the SQL an app uses in order that can review it for best practice.
• they are worried about performance (some people have "heard" the ORM's aren't as performant but have no real proof themselves - there may well be some truth in this! :).

So, I'm looking for the best or most convincing arguments that you have put forward FOR the use of ORM tools.

Equally, I would be interested in the against arguments too.

Note: this is NOT a discussion over which ORM I should use.

Answer 1

I would say that some projects lend themselves to being easier to work with ORM's than others. My current company has three big things going for it that made ORM a snap decision:

1. The application is very simple in that it does CRUD against basic objects.
2. There are very few joins involved when it comes to displaying data back to users in lists.
3. There is very little record contention and as such, not much decision making had to be put around transactions and the consequence of locking data.

Beyond that, remember, DB people are very risk adverse whereas Dev's are much more risk embracing. This question becomes much more about human psychology.

Answer 2

We have recently switched over to an ORM based approach and I can give you some negatives, but I'm hard pressed to find worthwhile positives. Most of this is due to the nature of our database.

Pros (note that both of these could be accounted for using SPs, ORMs make them easier, however):

• When it's something nice and simple, it'll be performant and clean.
• A lot of logic is pulled out of SPs and can therefore be tested.

Cons:

• When it's not nice and simple, the SQL will be garbage. You may not get the data back that you expect. It will be slow and will be incredibly difficult to tune.

• Our database is constantly changing. That means every couple of days someone needs to spend an hour updating the model to add a table or change datatypes that are changing (agile + ORM on a large constantly changing database is brutal).

Answer 3

Why does it have to be all or nothing? There's nothing to stop a DBA or database developer to create some sort of view, udf or stored procedure to handle something they feel is overly-complex or they want to have as much control as possible.

There are ways to capture the sql being created.

The performance of the ORM generated sql can be compared to something more optimized.

At some point creating and maintaining code has to be a consideration.

Answer 4

As far as I am concerned, the only legitimate reason I have heard for using object relational mapping (ORM) is if a switch to a different database engine is probable (not just possible). MySQL to Oracle would be an example (although I don't know why anyone would desire to make that particular change unless they absolutely had to). And even in that case an ORM may not be the best decision.

I heard one reference that bothered me that suggested that it is less competent programmers that are against ORM. One could just as easily say that it is programmer incompetent in SQL that are in favor of ORM. So lets not make that type of argument.

Reasons I am against ORM is that I believe it takes away from transparency and makes it difficult to make the inevitable ongoing tweaks that are a major part of all development cycle. If a developer is not fluent in a particular ORM and is hired and needs to make a database change, a task that would othersize take an hour could take many hours. So "rapid" application develop becomes "crippling" application maintenance.

I also believe that complex design patterns where one language automatically writes another language should be generally avoided. ORM isn't the only example of this, of course. Another example is PHP that writes out XHTML. Note every line of code we write needs to be be or should be object oriented. Embedding our markup language and query syntax rather than having our programming language "automagically" do it makes the application more transparent (easier to understand), debug, and maintain. Also, some may say that an ORM "frees" projects from the constraints of a particular database engine. But what about the constraints of your new "fadish" ORM engine? You can pretty much guarantee that the major database engines will be supported longer than most ORMs.

I would also like emphasize that ORM is not VMC, although a lot of VMCs are bundled with ORMs. It is perfectly valid, and I think desirable in most circumstances, to create models that contain hand crafted methods with hand written SQL.

I would also like to dispell one other myth--that ORM are connected to RAD or rapid application development. I do not buy this because in my personal experience I only spend about 10% of my time writing SQL and crafting models for CRUD. So even if ORM cut this time in half (and I don't think it does) then it would only be a 5% increase in my development time (which it isn't). And I'm not an SQL expert or DBA either--just a developer with average SQL skills. SQL is just not a big time sink as long are the DRY principle is followed and models are created with intention.

I personally believe there is a lot of "group think" around ORM--that developers say it should be used because everybody else says it should it be used; it's considered a "hot" technology that one can pad a resume with. Put it on your resume if you feel you must, but but don't use in an important project just because you feel you "should."

Answer 5

So, I'm looking for the best or most convincing arguments that you have put forward FOR the use of ORM tools.

There is no way to convince anyone who is against ORM.

You can, however, prove that ORM is better. But you can only do this with a fully-functioning ORM implementation that works, is fast, and much simpler than the equivalent SQL.

Also, you'll have to show how to turn on logging so they can watch the SQL go by.

1. Pick a project that has a controlled level of complexity. Rewriting an existing but broken application is often the best. The data structure is stable, the use cases are known, and you fabricate a unit test suite for measuring correctness and performance.

2. Implement that project with a super-clean ORM implementation. Super clean. No hacks. No workarounds. Nothing "funny" or outside the tutorial.

3. Put it into production.

4. Do maintenance.

5. Prove that you did it faster, with fewer errors and can do maintenance quicker because of the ORM. This will take a year or more.

Answer 6

In our company we have this against argument for ORM like:

We want control over our SQL.

I do not know how much of a difference it would make but I have always come across this argument.

Answer 7

I'm against ORM and database abstraction in general because:

1. It encourages people to put business logic (including access control) in the application (or library) not the database. This is bad, because it means if there's a need to do 1 app in a different language, the logic needs to be consistently re-implemented. It also means all developers need to be trusted with all data.
2. The ORM models I've seen are really intolerant of changes to database structure. So when a field is added to a table for 1 app, all apps need rebuilding/redeploying at the same time, possibly across multiple development languages and geographic locations. This is a maintenance nightmare.