Last post Apr 13, 2016 09:59 AM by rahulkishore
Mar 31, 2016 04:06 AM|mahavirjadhav|LINK
We have web application developed in Asp.net 3.5 with 3 tier architecture. At that time we have used ADO.net and stored procedure. Now we planning to convert it into SPA using AngularJS and asp.net Web API. We are confused whether to go with Entity framework
or ADO.net. As we are having stored procedures for CRUD operations will it be beneficial to use Entity framework or should we go ADO.net way.
Please give suggestions.
Mar 31, 2016 02:55 PM|deepalgorithm|LINK
Entity Framework is an ORM. Entity Framework can call stored procedures and you could create the correct mappings for your CRUD operations. It will abstract all the plumbing that you would otherwise have to do if you used ADO.NET.
Another option is to use Dapper, which is a micro ORM. Doesn't have all the features of Entity Framework, but its fast. It will be able to call your stored procedures and do basic mappings.
Apr 01, 2016 03:22 AM|Yohann Lu|LINK
As far as I know, writing and managing ADO.Net code for data access is a tedious and monotonous job. Microsoft has provided an O/RM framework called "Entity Framework" to automate database related activities for your application.
Entity Framework allows you to manage DB objects via strongly-typed classes and collections. It sits on top of ADO.NET so it can't be faster.
ADO.Net peeking into the DB using the old ADO objects SQLConnection, SQLCommand, SQLParameters.
From a technical point of view, Entity Framework may be more suitable for Web API.
You can refer the following tutorial.
1: Enterprise Level Application Architecture with Web APIs using Entity Framework, Generic Repository Pattern and Unit of Work:
2: Using Web API 2 with Entity Framework 6:
3: How fast is classic ADO.net compared to Entity Framework?
Apr 13, 2016 09:59 AM|rahulkishore|LINK
Hello, I've had some extensive experience with ADO.NET and Entity Framework both.
Like the other replies, EF is an ORM. And I need to make this clear, it is a slow ORM. But on the flipside, most of these ORMs are slow.
EF will be able to handle most of your database operations (running the stored procedures, running normal queriers, etc etc).
However, one problem that I did face with EF 6 was that in many of my queries I was only selecting a subset of columns. When I had to retrieve a subset of columns many times I was using LINQ. This turned out to be slow in EF.
Ended up scratching the whole thing and going to with NHibernate. NHibernate provides some more flexibility in terms of mappings AND query return types (you can safely cast it to a particular data type to match the columns you want fetched from your query).
Couldn't really do this with EF6.
My suggestion from the get-go is to use NHibernate if you're going to go with an ORM. Allows you this option to have parameterised queries and also allows you LINQ. And by parameterised queries, in the Hibernate world these are what you refer to as HQL.