This question is locked. New answers and comments are not allowed.
Hi,
I'll be starting a new MVC project and the timeline for this will be quite limited.
I wanted to use the ORM LINQ but i'm just curious on it's performance compared to Stored Procedure. Will this be a good solution in long term?
I know i could map stored procedure in ORM but i just want to skip this and focus more on the web development.
Many Thanks,
Marvin
I'll be starting a new MVC project and the timeline for this will be quite limited.
I wanted to use the ORM LINQ but i'm just curious on it's performance compared to Stored Procedure. Will this be a good solution in long term?
I know i could map stored procedure in ORM but i just want to skip this and focus more on the web development.
Many Thanks,
Marvin
1 Answer, 1 is accepted
0
Hi Marvin,
I can't give you a definite answer about performance comparison between LINQ and usage of Stored Procedures (or any plain ADO.NET). The answer is 100% dependent on your particular business scenario.
Generally LINQ will have more overhead because the runtime has to translate expressions into SQL statements rather than just executing SQL statements, but most of the ORM products offer many tools to mitigate that penalty by caching the compiled queries or caching the results and so on.
Whether the use of and ORM and LINQ is good in long term, my personal feeling is that it is. Having an ORM layer between you and the database takes away a lot of boilerplate code, allows you to enjoy the fruits of the work of lot of people thinking and solving issues in the data layer domain for quite some time. Of course your project may turn out to be really heavy on database side operations that are best performed on the SQL server level rather than in the application level. In this scenario you should consider Stored Procedures as your main tool to implement the application. For other scenario I personally will go for and ORM and LINQ and will enjoy the easier maintainability given that my whole application code is in single place and is expressed in a single language.
If you already have an implemented layer of Stored Procedures you may want to see which ones can be mapped directly to Domain Methods in Data Access and which can substitute the code executed on Create, Update and Delete operations for your entities.
If you have any further questions do not hesitate to contact us.
Regards,
Viktor Zhivkov
Telerik
I can't give you a definite answer about performance comparison between LINQ and usage of Stored Procedures (or any plain ADO.NET). The answer is 100% dependent on your particular business scenario.
Generally LINQ will have more overhead because the runtime has to translate expressions into SQL statements rather than just executing SQL statements, but most of the ORM products offer many tools to mitigate that penalty by caching the compiled queries or caching the results and so on.
Whether the use of and ORM and LINQ is good in long term, my personal feeling is that it is. Having an ORM layer between you and the database takes away a lot of boilerplate code, allows you to enjoy the fruits of the work of lot of people thinking and solving issues in the data layer domain for quite some time. Of course your project may turn out to be really heavy on database side operations that are best performed on the SQL server level rather than in the application level. In this scenario you should consider Stored Procedures as your main tool to implement the application. For other scenario I personally will go for and ORM and LINQ and will enjoy the easier maintainability given that my whole application code is in single place and is expressed in a single language.
If you already have an implemented layer of Stored Procedures you may want to see which ones can be mapped directly to Domain Methods in Data Access and which can substitute the code executed on Create, Update and Delete operations for your entities.
If you have any further questions do not hesitate to contact us.
Regards,
Viktor Zhivkov
Telerik
Telerik has recently updated some of its product names. You can check out the Telerik Product Map here (www.telerik.com/name-mapping). OpenAccess ORM is now renamed to Telerik Data Access.