Just answered a question on Linked-In regarding ORM vs. SQL for real world projects...here is my answer:
OK...Since I'm a consultant, I'll give you the consultant answer - "It depends".
Using an ORM such as Entity Framework makes it VERY easy to run CRUD routines against a database without having to do ANY stored procedures (or any other SQL for that matter). What you lose when you do that is the ability to fine tune the queries or have a lot of control of what the ORM will generate. Oh, yea...I know some will argue that you have a lot more control, but bottom line the tool is still generating SQL for you to perform that operation. A lot of DBAs don't like that because they too lose some control of what is actually happening on the database and the SQL being generated.
Managers love it because productivity is ramped up because we aren't generating a lot of SPROCs and other object code that takes time and has to be maintained.
You hit it on the money that if you want to go with the SQL approach, you will gain some performance because you lose a layer in the ORM, and have the ability to fine tune your queries - as well as them living on the DB server. BUT...you lose some productivity because now you need to generate those CRUD procedures as well as create the business layer around them. Using a tool like MyGeneration can mitigate that some, but you still have code to maintain.
Bottom line, if HIGH performance is an issue, then I would stick to the old fashion, tried-and-true SPROCs and associated objects layers. However, for most real-world line-of-business applications where you have a few dozen or a few hundred users and a "normal" level of performance is expected, then I would take advantage of the productivity enhancements gained by the ORMs.
0 comments:
Post a Comment