I'm wondering if there's a performance penalty when doing the following vs using plain old ado.net DataReader and DataTable:
using(DBEntities dbEntities = new dbEntities)
{
ObjectResult<tblCustomers> customers =
dbEntities.ExecuteStoreQuery<tblCustomers>("SELECT name,id FROM tblCustomers");
}
I would also like to run sprocs using dbEntity.
I mention this because i'm developing a highly performance sensitive application but would still like to use the entity framework.
furthermore, can anyone point me to recent performance tests of linq to entities compiled queries on .net 4.0?
EDIT
If i go with ado.net i plan on inserting the results i get from each row to a .net object manually. So it's entity framework storequery/sproc vs ado.net + manually creating and inserting data to a .net object.
Yes, of course - this is a higher-level approach than plain ADO.NET / SQL.
You send in a SQL query and get back a list of tblCustomers objects. Somewhere along the line, a mapping from the database's row/column to the object will happen, and this does take some time.
On the other hand - if you want to do the same thing yourself, you will have to pay a performance penalty, too - or you just use the old-style row/column to do your work (not recommended!).
It's the classic "convenience vs. performance" trade-off - what is more important to you? Being able to program with nice C# objects and their properties and be very productive as a programmer - or a few nanoseconds on the SELECT from your database? It's your pick....
Related
we are at the beginning of a new project, which will replace a legacy project. The legacy one is written in .Net Framework 4.0 (SOA with WCF) + SQL Server. The connection with SQL is made by ADO.Net + stored procedures. There is a structural mistake by having most of the logic on the stored procedures, and on top of that, it is a monolytic.
The new project will be made with .Net 6 APIs and in some cases, it will have SQL Server as well, for operational data.
So, looking at the new product the question was raised: should we move from ADO.Net to EF? This is tempting since it reduces the development effort, but performance is a concern.
Taking a look at the technical must haves:
Get the product to be as fast as possible (performance is a concern)
The new project is expected to live at least for the next 15 years
Operations are executed against tables with 30 to 50 million records
We must be able to run operations against the regular database, but also against the readonly one (AlwaysOn)
We must be able to perform some resiliency policies such as retries in case of deadlocks
We don't have much room for changes if we choose one path and somewhere along the way we realize we should had gone with the other option
Quite honestly, IMHO, based on our tech requirements I feel should move forward with ADO.Net + Stored procedures (without any business logic) + some sort of package that translates the SQL results to my objects in a fast manner, but I'd like to give EF a shot, at least on this stage of the process where we are investigating possibilities.
I'd like to gather if possible opinions, specially if there is someone out there that went to EF with requirements as similar as ours, or someone who didn't go to EF or had to change from EF to ADO.Net somewhere along the way.
Thanks.
The only thing in your requirements that could support using ADO.NET over EF is
Get the product to be as fast as possible (performance is a concern)
Which is a nonsense requirement, as you can always write more code and make things more complex to make things marginally faster. You need a real performance requirement so you can measure different approaches.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm new to using ORM in dealing with database, Currently I'm making a new project and I have to decide if i'll use Entity Framework or Dapper. I read many articles which says that Dapper is faster than Entity Framework.
So I made 2 simple prototype projects one using Dapper and the other uses Entity Framework with one function to get all the rows from one table.
The table schema as the following picture
and the code for both projects as the following
for Dapper project
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
IEnumerable<Emp> emplist = cn.Query<Emp>(#"Select * From Employees");
sw.Stop();
MessageBox.Show(sw.ElapsedMilliseconds.ToString());
for Entity Framework Project
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
IEnumerable<Employee> emplist = hrctx.Employees.ToList();
sw.Stop();
MessageBox.Show(sw.ElapsedMilliseconds.ToString());
after trying the above code many times only the first time I run the project the dapper code will be faster and after this first time always I get better results from entity framework project
I tried also the following statement on the entity framework project to stop the lazy loading
hrctx.Configuration.LazyLoadingEnabled = false;
but still the same EF performes faster except for the first time.
Can any one give me explanation or guidance on what makes EF faster in this sample although all the articles on the web says the opposite
Update
I've changed the line of code in the entity sample to be
IEnumerable<Employee> emplist = hrctx.Employees.AsNoTracking().ToList();
using the AsNoTracking as mentioned in some articles stops the entity framework caching and after stopping the caching the dapper sample is performing better, (but not a very big difference)
ORM (Object Relational Mapper) is a tool that creates layer between your application and data source and returns you the relational objects instead of
(in terms of c# that you are using) ADO.NET objects. This is basic thing that every ORM does.
To do this, ORMs generally execute the query and map the returned DataReader to the POCO class. Dapper is limited up to here.
To extend this further, some ORMs (also called "full ORM") do much more things like generating query for you to make your application database independent, cache your data for future calls, manage unit of work for you and lot more. All these are good tools and adds value to ORM; but it comes with cost. Entity Framework falls in this class.
To generate the query, EF have to execute additional code. Cache improves the performance but managing the cache needs to execute additional code. Same is true for unit of work and any other add-on feature provided by EF. All this saves you writing additional code and EF pays the cost.
And the cost is performance. As Dapper does very basic job, it is faster; but you have to write more code. As EF does much more than that, it is (bit) slower; but you have to write less code.
So why your tests show opposite results?
Because the tests you are executing are not comparable.
Full ORMs have many good features as explained above; one of them is UnitOfWork. Tracking is one of the responsibilities of UoW. When the object is requested (SQL query) for first time, it causes round trip to database. This object is then saved in memory cache. Full ORM keeps track of changes done to this already loaded object(s). If same object is requested again (other SQL query in same UoW scope that include loaded object), they do not do database round trip. Instead, they return the object from memory cache instead. This way, considerable time is saved.
Dapper do not support this feature that causes it to perform slower in your tests.
But, this benefit is only applicable if same object(s) loaded multiple times. Also, if number of objects loaded in memory is too high, this will slow down the full ORM instead as then the time required to check the objects in memory will be higher. So again, this benefit depends on use-case.
I read many articles which says that Dapper is faster than Entity Framework
The problem with the most of the benchmarks on internet is that they compare EF Linq to Dapper. And that's what you did too. Which is unfair. An auto generated query(EF) is often not equal to the one written by a good developer.
This,
IEnumerable<Employee> emplist = hrctx.Employees.ToList();
should be replaced by this.
IEnumerable<Employee> emplist = hrctx.Employees.FromSql(#"Select * From Employees").AsNoTracking();
Edit:
As pointed out by #mjwills, below is the results table for insert, update and select statements.
Dapper is outperforming EF Core 2. However, it can be seen that for EF plain queries, the difference is very minimum. I have posted complete details here.
There is no problem to mix them together. In my current project I'm using Dapper for selecting data and EF for creating and updating and database migrations.
Dapper becomes exteremely helpful when it comes to complex queries where more than two tables are involved or where there are some complex operations (joining by more than one column, joining with >= and <= clauses, recursive selections, cte's etc) where to use pure SQL is much easier than LINQ. As I know, Entity Framework (unlike Dapper) cannot use .FromSql() method on custom DTO's. It can map only one table that should be in your database context.
The article Entity Framework Core 2.0 vs. Dapper performance benchmark, querying SQL Azure tables confirms that Dapper is a bit quicker, but not enough to ignore "full ORM" benefits.
EF is so widely used staff but I don't realize how I should use it. I met a lot of issues with EF on different projects with different approaches. So some questions brought together in my head. And answers leads me to use pure ado.net with stored procedures.
So the questions are:
How to deal with EF in n-tier application?
For example, we have some DAL with EF. I saw a lot of articles and projects that used repository, unit of work patterns as some kind of abstraction for EF. I think such approach kills most of benefits that increase development speed and leads to few things:
remapping of EF load results in some DTO that kills performance(call some select to get table data - first loop, second loop - map results to some composite type generated by ef, next - filter mapped data using linq and, at last, map it to some DTO). Exactly remapping to DTO is killer of one of the biggest efs benefit;
or
leads to strong cohesion between EF (and it's version) and app. It will be something like 2-tier app with dal and presentation with bll or dal with bll and presentation. I guess it's not best practice. And the same loading process as we have for previous thing except mapping, so again performance issue raised up. We could try to use EF as DAL without any abstraction under them. But we will get similar issues in some other way.
Should I use one context per app\thread\atomic operation? Using approach - one context per app\thread may slightly increase performance and possibilities to call navigation properties, but we meet another problem - updating this context and growing loaded data in context, also I'm not sure about concurrency with one dbcontext per app\thread. Using context per operation will lead us to remapping EF results to our DTO's. So you see that we again pushed back to question no.1.
Could we try to use EF + stored procedures only? Again we have issues from previous questions. What is the reason to use EF if the biggest part of functionality will not be used?
So, yes EF is great to start project. It so convenient when we have few screens and crud operations.
But what next?
All this text is just unsorted thoughts. I know that pure ado.net will lead to another kind of challenges.
So, what is your opinion about this topic?
By following the naming conventions , you will find it's called : ADO.NET Entity Framework , which means that Entity Framework sits on top of ADO.NET so it can't be faster , It may perform both in equal time , but let's look at EF provides :
You will no more get stuck with writing queries without any clue about if what you're writing is going to compile or not .
It makes you rely on C# or your favorite .NET language on writing your own data constraints that you wish to accept from the target user directly inside your model classes .
Finally : EF and LINQ give a lot of power in maintaining your applications later .
There are three different models with the Entity Framework : Model First , Database First and Code First get to know each of 'em .
-The Point about killing performance when remapping is on process , it's because that on the first run , EF loads metadata into memory and that takes time as it builds in-memory representation of model from edmx file.
ADO. Net is an object oriented framework that allows you to interact with database system (SQL, Oracle, etc).
Entity framework is a techniques of manipulating data in databases like (collection of queries (inert table name , select * from like this )).
it is uses with LINQ.
Entity Framework is not efficient in any case as in most tools or toolboxes designed to achieve 'faster' results.
Access to database should be viewed as a separate tier using store procedures as the interface. There is no reason for any application to have more than absolutely require CRUD operations. Less is more principle. Stored procedures are easy to write, secure, maintain and is de facto fastest way. It's easy to write tools to generate desired codes for POCO and DbContext through stored procedures.
Application well designed should have a limited numbers of connection strings to database and none of which should be the all mighty God. Using schema to support connection rights.
Lazy loading are false statements added to solve a problem that should never exist and introduced with ORM and its plug and play features. Data should only be read when needed. Developers should be responsible to implement this logic base on application context.
If your application logic has a problem to maintain states, no tool will help. It will in fact, make it worse by cover up the real problem until it's too late.
Database first is the only solution for a well designed application. Civilization realized long time ago the important of solid aqueduct and sewer system. High level code can and will be replaced anytime but data stays. Rewrite an entire application is matter of days if database is well designed.
Applications are just glorified database access. Still true in most cases.
This is my conclusion after many years in business applications debugging through codes produced by many different tools or toolboxes. The faster results advertised are not even close to cover the amount of time/energy wasted later trying to clean up the mess. Performance issues are rarely if not ever caused by high demand but the sum of all 'features' added through unusable tools.
ADO.NET provides consistent access to data sources such as SQL Server and XML, and to data sources exposed through OLE DB and ODBC. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, handle, and update the data that they contain.
Entity Framework 6 (EF6) is a tried and tested object-relational mapper (O/RM) for .NET with many years of feature development and stabilization. An ORM like EF has the following advantage
ORM lets developers focus on the business logic of the application thereby facilitating huge reduction in code.
It eliminates the need for repetitive SQL code and provides many benefits to development speed.
Prevents writing manual SQL queries; & many more..
In an n-tier application,it depends on the amount of data your application is handling and your database is managing. According to my knowledge DTO's don't kill performance. They are data container for moving data between layers and are only used to pass data and does not contain any business logic. They are mostly used in service classes.See DTO.
One DBContext is always a best practice.
There is no such combination of EF + SP(Stored Procedure) as per my knowledge. If you wish to use an ORM like EF and an SP at the same time try micro-ORMs like Dapper,BLToolkit, etc..It was build for that purpose and is heck lotta fast than EF. Here is a good article on Dapper ORM.
Here is a related thread on a similar topic: What is the difference between an orm and ADO.net?
I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?
ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.
LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures
LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.
The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.
In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.
I've been programming in C# 2.0 WinForms for a while now. I'm starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I've only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I'm all for it.
I followed the tutorials on the www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.
My questions are:
Is one method better than the other?
What are the benefits of one over the other?
Is it possible to see the SQL that is generate when using either of the methods?
Since I'm new to the ASP world, are web developers leaning on one side?
2: LINQ-to-SQL has the benefits of being simple (but still well engineered) - but the downside of being simple ;-p
LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
Entity Framework supports more abstraction between the data (storage) model and the object model - LINQ-to-SQL is literal table/column => class/property[|field]
LINQ-to-SQL is actually more "complete" in the stuff it does do:
EF doesn't support UDFs
EF doesn't support things like sub-expression invoke (for custom expression trees)
EF doesn't support some "obvious" methods like Single()
EF doesn't have some of the TSQL optimisations that LINQ-to-SQL uses
Basically EF at the moment is a bit more of a "v1" (or even "v0.9") product. However (and importantly) - EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.
At the moment, I'm very happy to use LINQ-to-SQL, but EF is on the long term... so I'm using repository etc to hide some of the gory implementation details - a bit of a leaky repository, but pragmatic.
3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well - or I have one that writes to the trace.asax. With EF, ToTraceString.
4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I'm wondering how much this will change when EF is next released in .NET 4.0...
Use the one that feels best for you, your team and your project. It doesn't really matter how you access the data, as long as you access it.
You could use plain old ADO.NET if you want.