I am trying to use dapper-dot-net to speed up some area of my asp.net mvc application. I am using EF5 Code first also.
Since dapper-dot-net is just some extensions for IDbConnection, can i just use
DbContext.Database.Connection
to use dapper-dot-net? I test it is working. However, i am not sure this is the right way to use it? Especially, when I use that way, will Entity Framework still has some impact that could hurt the performance?
Using Dapper could be a significant performance improvement in certain scenarios.
You can share the EF connection with Dapper. However (although unlikely to be a problem) you should be mindful of concurrency issues (e.g. due to attempts to associate multiple data readers with the same connection).
If you do run into such issues, you have the option of giving a new connection to Dapper using the connection string (DbContext.Database.Connection.ConnectionString), instead of sharing the connection.
Yes, you can use it that way. Since Dapper is just working on extension methods, you can use it for the performance-sensitive areas of your code. And you can continue to use EF for other areas of your code. The queries that you have that are still using EF will not be as fast - but at least the queries using Dapper will be faster.
I think you have to rethink about the question. Increasing performance via changing the ORM is not a good technique. It is correct that dapper is faster and lighter than EF but this does not mean that to increase the speed of your application its better to use the dapper. EF is powerful enough to handle the whole data layer if you suffer from performance you have to introduce new feature like caching or no sql db.
you have to see that changing from EF to dapper how much will save time for you ? and how much speed can caching bring to your application.
and adding dapper has other expenses: how would you manage the transaction while you have to point of save and update how you are going to solve the roll back situation, what about the Unit of Work and Repository pattern.
These are the factor that you have to examine before deciding to go for Dapper.
Related
Please mention the reason of Fast execution of dapper ORM by comparing Entity Framework and ADO.NET. I got the reference for comparison from the link dapper vs entity framework
It can never happen that Dapper is much faster than ADO.Net. Period!
We know that Dapper team has written an advance mechanism via IL to just speed-up the process, but still it is running on top of ADO.Net. They are only abstracting the ADO.Net and processed everything on top of it by converting the actual data (rows) back to the object models (POCO or DTO), and that would add additional time doing it.
I think everyone must understand the separation of concern of the ADO.Net layer from any other ORM available on this world.
Or else or unless, the Dapper team will write their own version of DbDataReader, then, there could be a possibility that they are much faster, but never ever it will happen until they do it.
With EF, there is no question that Dapper is much faster than it as they are the most lightweight ORM right now that is available.
IMHO
I have a question about JPA/Hibernate performance.
We are building web application, one of the goals is to store questions and their answers. For both of these things we have class hierarchy, and #Inheritance(strategy = InheritanceType.TABLE_PER_CLASS).
The questions have references to their answers, every question is stored in some list.
I observed using firebug that when I am adding new question to the list and use entityManager.merge I need to wait about one second for response. I think that it is pretty long time to wait for a response for simple add request.
Is it because of the Inheritance strategy, or maybe I shouldn't use entityManager.merge and try to write my own query.
Maybe the performance is low because I am using sql lite database (sql lite is used just for testing, on production postgre will be used)?
Or this kind of performance is pretty standard for ORM solutions.
I use sqlite a lot (sometimes even for production) and the performance is sometimes even better than for traditional client server connections.
Maybe you should debug you application and enable logging of the JPA provider you are using to see if in fact the inheritance model is to blame.
But, if you have done the inheritance correctly then I don't think that would be te issue. It would help if you paste the code for how you declare the classes.
I would also look at a profiler if this persists.
We have an app in ASP.NET MVC 3 that, due to legacy and porting reasons, is written entirely using traditional ADO.NET for the data layer.
I am now tasked with adding some reporting to this website, and the reports can result in some extremely complicated queries.
Are there any pitfalls in using the EF Power Tools to reverse-engineer a code first model and using it side-by-side with our current ADO.NET model? Doing so would allow me to use LINQ for querying the data I need, greatly speeding up the time required to write each report. I would need to shut off data context initialization, as we have our current model do that, but are there any glaring risks or problems associated with trying to do this?
If it's of any relevance (I know EF 5 has a ton of new features), we are using .NET 4 and will begin moving to .NET 4.5 as soon as it launches.
I think this is a very sensible thing to do. You could also use a database-first model, which you can refresh whenever the database changes and which does not try to initialize a database.
Since you will use the context read-only you can optimize the query process by setting the MergeOption property of ObjectQuerys to MergeOption.NoTracking. This reduces overhead because the context will not track changes of the generated objects.
A problem might be that there is more maintenance if the database changes, but I think the absence of walls of boiler-plate query code for reporting on the old data layer far outweighs that.
One day :) you may even decide to use the EF model to display data that users want to filter in the UI and use the old data layer for CUD commands. (a bit like CQRS).
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
Currently we have a project to implement an Internet Banking site, and we are evaluating using Nhibernate on it. ¿Is NHibernate suitable for this kind of application, where performance is important and there will be a large quantity of users doing operations simultaneously?
¿Do you know any successfull stories of using NHibernate in this kind of environment?
I think NHibernate is slow only when is used incorrectly, and I think we can use it with a lot of tweaking, best practices and common sense.
UPDATE: We were contacted for the project not too long ago, and we are still collecting requirements to define the specs. The application its for a small to medium bank in our country, so they expect around a 200 - 300 users as a top simultaneously.
Im pretty sure the DB will be in SQL Server 2005, and will be a n-tier application using webservices to access the data layer.
My team has been using NHibernate in a system requiring high throughput for years without a problem. NH is fairly efficient to begin with, and provides fine-grained control over when and how objects are reconstituted.
With that said, we don't know the specifics of your problem, so we can't make certain predictions. Perform scaling tests before you commit yourself.
NHibernate can be suitable if used correctly.
But, don't pin you down on this answer, since we do not know the correct specs.