May 11, 2010 at 8:05 pm
Comments posted to this topic are about the item The ORM Dilemma
May 12, 2010 at 2:53 am
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.
May 12, 2010 at 5:24 am
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.
May 12, 2010 at 6:36 am
I can't contribute much because you made me Google ORM. I guess I'll just follow the thread.
May 12, 2010 at 6:47 am
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/
May 12, 2010 at 6:53 am
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.
May 12, 2010 at 7:35 am
Amen brother!
May 12, 2010 at 7:43 am
@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.
May 12, 2010 at 8:13 am
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.
May 12, 2010 at 8:25 am
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.
May 12, 2010 at 8:27 am
OK, ok...I'll bite.....What does 'ORM' stand for?
{Does this make me really stupid??} 😀
May 12, 2010 at 8:37 am
May 12, 2010 at 9:09 am
Thanks Steve. Back in my old mainframe days we called this practice "interface programming" and it ALWAYS had to be done by hand. and some times would involve more than one step to get the data in the form you needed it in the database or new system.......or am I missing something here? I honestly can't conceive of an automated tool that would properly handle any and all data circumstances or edits that would be required to interface two systems together. Sounds like a pipe dream to me.
May 12, 2010 at 9:32 am
I haven't done a lot of work here. You might check out Grant Fritchey's post on it. He does more development.
nHibernate is a very well known ORM system, but there are others. They are designed as a framework that makes it easy for developers to query objects, and let the system build SQL, and handle mapping to the relational store. Some require an object for each table, some don't.
http://scarydba.wordpress.com/2010/04/09/thoughts-on-orm/
http://en.wikipedia.org/wiki/NHibernate
http://nhforge.org/wikis/howtonh/your-first-nhibernate-based-application.aspx
http://inchoo.net/zend/doctrine-orm-and-zend-framework-sample-project-to-get-you-started/
May 12, 2010 at 11:00 am
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply