Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

The ORM Dilemma Expand / Collapse
Author
Message
Posted Tuesday, May 11, 2010 8:05 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:38 PM
Points: 31,368, Visits: 15,834
Comments posted to this topic are about the item The ORM Dilemma






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #920123
Posted Wednesday, May 12, 2010 2:53 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 25, 2010 5:33 AM
Points: 5, Visits: 27
As a developer having finished a couple of large projects using an ORM (Entity Framework) I can tell you that they add more than they take away. Most DBAs take issue with ORM frameworks because they feel they are giving their baby up for adaption. But if you consider that some frameworks such as Entity Framework still allow you to use CRUD stored procedures, Views and Transactions then there is not that much to be worried about.

Yes you do loose some finite control but it rarely a large issue. Yes in a very high performance scenario were sub seconds are important then I would second guess the use of an ORM and would really test the performance hit of using one before deciding on its implementation. But where the requirements for the application contains a lot of complex business rules and ongoing maintenance is likely to be a significant cost then an ORM definitely makes sense.

Using an ORM simply put increases productivity. Therefore gentlemen I would just get used to it. These frameworks are here to stay and it is best that you educate yourself about the various frameworks so that you can make a positive contribution to the discussion rather than being a roadblock to productivity.
Post #920252
Posted Wednesday, May 12, 2010 5:24 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 1:17 PM
Points: 1,894, Visits: 481
I think it depends on what your project needs are. If you have a more simple project with a simple db design something like the entity framework can work. I am still a little concerned over the scaleability of the entity framework. We recently used it in a new product we were developing. The bottom line was the product had a lot of complicated things that the entitiy framework just did not do well with. So in the end a number key pieces of functionaility had to be written in stored procs because the entity framework just couldn't do the work in a timely manner. Also the performance was not great even with the simple screens. Unfortunately for us it appears we will have to re-write this product without the entity framework before we can go to market with it. So in our case the entity framework has cost us a lot of money and time. Honestly we wish we had not used the entity framework to begin with.
Post #920343
Posted Wednesday, May 12, 2010 6:36 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, February 4, 2011 7:20 AM
Points: 977, Visits: 1,499
I can't contribute much because you made me Google ORM. I guess I'll just follow the thread.

Tom Garth
Vertical Solutions

"There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers
Post #920399
Posted Wednesday, May 12, 2010 6:47 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: 2 days ago @ 6:03 AM
Points: 94, Visits: 596
We are even going through the debate currently of productivity vs performance. It will be interesting to see if the developers can pull off a quality ORM deployment. I hope they can deliver automated load testing so we can verify this thing won't eat up the Nehalem's when it goes live.....

@Justin - There is very little that a DBA needs to know about the ORM tools. The database needs to be designed properly; the rest is up to the ORM/Developer. Developers seem to see the roadblock to productivity as the initial code writing, but DBAs have to live with the implications for the life of the application. So is productivity only to release, or the time it takes to get the app to function properly and run without constant babysitting?

This will basically force developers to become administrators of their systems and the data layer, and the DBAs will simply gather metrics and send out reports showing why things are slow. Their power to fix them will have been diminished considerably. Personally, I know few developers who want the responsibility, and when I put it to them like that, they go back to writing procs.

The Scary DBA reflected on the problems awhile back, the one that many DBAs that I have talked to, encounter.-> http://scarydba.wordpress.com/2010/04/05/nhibernate-first-look-at-tsql/


Cheers
http://twitter.com/widba
http://widba.blogspot.com/
Post #920408
Posted Wednesday, May 12, 2010 6:53 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, October 9, 2014 8:58 AM
Points: 13, Visits: 107
ORM Frameworks are tools, and as with anything else, you need to use the right tool for the right job. Use the wrong tool, and you will break something.

I believe ORMs have their place, and if you can override their automatic SQL generation when needed to ensure good performance, then you are all set.

I had one project where it was critical for me to represent data in business objects, not just datasets. I estimated that in order for me to properly design the business objects and data access layer to not only hold data, but manage state, change tracking, concurrency, relationships, etc, it would have taken me about two weeks minimum. Using the Entity Framework, I was able to complete the same task in about 3 days.

ORMs are not the be-all-end-all of data access, but when used appropriately and for the appropriate tasks, they are good tools for getting the job done.
Post #920416
Posted Wednesday, May 12, 2010 7:35 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 25, 2010 5:33 AM
Points: 5, Visits: 27
Amen brother!
Post #920466
Posted Wednesday, May 12, 2010 7:43 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 25, 2010 5:33 AM
Points: 5, Visits: 27
@bkubicek I am surprised that a possible rewrite is necessary since you can use stored procedures inside of Entity Framework. I had the same problem for some instances where the standard LINQ functionality was not a good fit and therefore I went with stored procedure for some things but still inside of Entity Framework.

It might be a case where the development team is not fully leveraging the possibilities of the ORM.
Post #920475
Posted Wednesday, May 12, 2010 8:13 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 1:17 PM
Points: 1,894, Visits: 481
The reason we decided the rewrite is necessary is that the performance is poor even with very little data in the test database. It is surprising how sluggish the web UI is with so few records to return. We considered only rewriting the pieces that were too complicated for the entity framework. Actually, we started down that path, but we could not resolve the UI sluggishness without removing the entity framework.
Post #920514
Posted Wednesday, May 12, 2010 8:25 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, December 15, 2014 3:27 AM
Points: 337, Visits: 2,282
The CRUD concept itself is very old (I know of implementations from over 20 years back). It is also kind of crude/limiting in that operations apply per record (from what I have seen myself). This is counter to more efficient set based thinking, which you need to do when working with large volumes of data.

In a way, completely depending on CRUD is a step wackwards to the day when there were products that had triggers that fired per record instead of per set of records. As a developer I can see the ease of use however, but it should never be implemented in a way that reduces the options for a DBA to optimize things after deployment.

If you need one record, manipulate one and store one, CRUD is fine. Beyond that, it becomes itself a roadblock for performance and efficiency.
Post #920526
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse