I have a question. I have used ADO and Entity Framework. No doubt, Entity Framework facilitates us for writing queries in c# so we can also debug these queries. Till now what I have heard is that query processing is more fast if we execute them in SQL. So I just want to know that processing queries in c# could be slower than processing them in SQL? What I want to say is that query written in Entity framework would be slow/fast than query written in SQL?
I hope I am clear.
Please suggest.
SQL will be faster but by how much depends on your queries. So there is no definite answer as you will have to test the results for yourself.
In my experience the performance of the entity framework is generally acceptable. If 95% of your queries are fast enough in EF then you can always write the remaining slow 5% in SQL.
There are similar thread here: Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures?
I this thread will help you make decision what are good/bad of both.
Related
The project I am working on has 90% of the business logic in stored procedure. I looked at Dapper as a possible path to move some of these business rules to the Application layer. The benefits to me are evident, in that I can do unit testing etc etc.
Dapper seems to help with mapping objects, to classes through sql queries. This is not enough for me, because I'd like to build my queries into an application class like service, and then unit test them before I go to my Repository( aka Dapper).
I'd expect the ORM to translate my query into sql. Dapper seams not to be meant to be used this way. So I wonder what is the point if I still have to build all my business logic in sql.
My question, is do I need a different ORM like hibernate? I guess I am looking for some guidance on how to evaluate this tool.
My experience is that ORM frameworks exist on a spectrum of features and sophistication, often with inversely related compromises in speed and ease of use.
For me, Dapper is right at the end of the spectrum in terms of features and sophistication but with the trade-off that it's speed is exceptional. That's not to say that Dapper is unsophisticated and feature-less, just that it doesn't have features like sessions, query building, etc. that you will find in ORMs at the other end of that spectrum, e.g. NHibernate.
If you want an ORM that will build SQL queries based on an object-oriented domain model, then Dapper is not for you. NHibernate, Entity Framework, LLBLGen and ORMLite(?) are options you can look into. N.b. I expect there are others I've missed.
You have to have a look at SQL Plus Dot Net. It is entity framework in reverse, that is, where entity framework build SQL statements from your C# code, SQL+ .net builds C# code from your SQL.
It truly is the first real innovation in data access in quite a while.
What is the most efficient way to get the sql query from EF? I need this so I can run the query analysis and find its execution plan.
I know I can hook profiler to SQL server, but this step is a pain and a tremendous hit on productivity, almost enough to give up ORM altogether.
Is there a better, more efficient way to optimize EF queries?
The ToTraceString method can do this for you.
If you cast your IQueryable to a ObjectQuery, you can use the ToTraceString()-method to see the SQL query.
Is there a better, more efficient way to optimize EF queries?
Yes, buy EF Profiler or Huagati Profiler. Alternatively use EF Provider wrapper for tracing.
I know I can hook profiler to SQL server, but this step is a pain and
a tremendous hit on productivity, almost enough to give up ORM
altogether.
Profiler is only half of the story. There is also Database Engine Tuning Advisor and these tools are the main tool set if you really want to optimize SQL queries - but optimizing SQL queries you don't have under your control is very hard and sometimes impossible.
This might be a very vague question but I guess I don't really understand what is going on. I asked a question earlier where I was told a simple way to "bind data to objects" is to just run a SqlConnection(connectionString). The response also included a comment saying I could get fancy with L2S and Entity Frameworks, so I looked deeper into those. It seems all you have to do with the DataContext object is point to the database. Why would SqlConnection be a benefit?
What is the difference (or pros/cons) of using either one of these? Is one more "standard"? Is one more modern?
P.S. I asked a lot of questions that don't all need to be answered. I just wanted to add some clarity to my question and how much I don't really understand this topic.
SqlConnection is part of the base, raw ADO.NET class library - the SQL Server part of that library, really. This is the foundation of all data access in .NET.
With raw ADO.NET, you're pretty "bare-bones" and close to the metal - you have to create your SQL queries and execute them, you get back rows and columns, very much like a relational database will give you.
Pros: really close to the SQL, really powerful, best performance
Cons: harder to write, more "glue" code, less type safety, tighter coupling to the underlying database structure
DataContext (Linq-to-SQL) or ObjectContext (Entity Framework) are higher level abstractions - they sit on top of ADO.NET, but they (Linq-to-SQL or Entity Framework) offer so called ORM capabilities - here, you're not really dealing with raw SQL statements and rows/columns, instead, those code generators will create an abstraction layer for you - which is built up from .NET objects. Each table in the database will be turned into a corresponding .NET class, with properties for all the columns in that table.
Also, with L2S and EF, you're typically using LINQ to query - your queries are much more C# like code, and L2s / EF will handle translating those queries you express in C# into actual SQL statements that SQL Server will execute.
Pros: much easier to work with, much nicer to handle (objects with properties vs. raw rows/columns), type safety, ability to query with LINQ, higher dev productivity
Cons: another layer means more translations, a hit on performance, not well suited for certain things (like bulk operations)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
How would you rate each of them in terms of:
Performance
Speed of development
Neat, intuitive, maintainable code
Flexibility
Overall
I like my SQL and so have always been a die-hard fan of ADO.NET and stored procedures but I recently had a play with Linq to SQL and was blown away by how quickly I was writing out my DataAccess layer and have decided to spend some time really understanding either Linq to SQL or EF... or neither?
I just want to check, that there isn't a great flaw in any of these technologies that would render my research time useless. E.g. performance is terrible, it's cool for simple apps but can only take you so far.
Update:
Can you concentrate on EF VS L2S VS SPs rather than ORM VS SPs. I'm mainly interested by EF VS L2S. But am keen to have them compared against stored procs too since plain SQl is something I know a lot about.
First off, if you're starting a new project, go with Entity Framework ("EF") - it now generates much better SQL (more like Linq to SQL does) and is easier to maintain and more powerful than Linq to SQL ("L2S"). As of the release of .NET 4.0, I consider Linq to SQL to be an obsolete technology. MS has been very open about not continuing L2S development further.
1) Performance
This is tricky to answer. For most single-entity operations (CRUD) you will find just about equivalent performance with all three technologies. You do have to know how EF and Linq to SQL work in order to use them to their fullest. For high-volume operations like polling queries, you may want to have EF/L2S "compile" your entity query such that the framework doesn't have to constantly regenerate the SQL, or you can run into scalability issues. (see edits)
For bulk updates where you're updating massive amounts of data, raw SQL or a stored procedure will always perform better than an ORM solution because you don't have to marshal the data over the wire to the ORM to perform updates.
2) Speed of Development
In most scenarios, EF will blow away naked SQL/stored procs when it comes to speed of development. The EF designer can update your model from your database as it changes (upon request), so you don't run into synchronization issues between your object code and your database code. The only time I would not consider using an ORM is when you're doing a reporting/dashboard type application where you aren't doing any updating, or when you're creating an application just to do raw data maintenance operations on a database.
3) Neat/Maintainable code
Hands down, EF beats SQL/sprocs. Because your relationships are modeled, joins in your code are relatively infrequent. The relationships of the entities are almost self-evident to the reader for most queries. Nothing is worse than having to go from tier to tier debugging or through multiple SQL/middle tier in order to understand what's actually happening to your data. EF brings your data model into your code in a very powerful way.
4) Flexibility
Stored procs and raw SQL are more "flexible". You can leverage sprocs and SQL to generate faster queries for the odd specific case, and you can leverage native DB functionality easier than you can with and ORM.
5) Overall
Don't get caught up in the false dichotomy of choosing an ORM vs using stored procedures. You can use both in the same application, and you probably should. Big bulk operations should go in stored procedures or SQL (which can actually be called by the EF), and EF should be used for your CRUD operations and most of your middle-tier's needs. Perhaps you'd choose to use SQL for writing your reports. I guess the moral of the story is the same as it's always been. Use the right tool for the job. But the skinny of it is, EF is very good nowadays (as of .NET 4.0). Spend some real time reading and understanding it in depth and you can create some amazing, high-performance apps with ease.
EDIT: EF 5 simplifies this part a bit with auto-compiled LINQ Queries, but for real high volume stuff, you'll definitely need to test and analyze what fits best for you in the real world.
Stored procedures:
(+)
Great flexibility
Full control over SQL
The highest performance available
(-)
Requires knowledge of SQL
Stored procedures are out of source control
Substantial amount of "repeating yourself" while specifying the same table and field names. The high chance of breaking the application after renaming a DB entity and missing some references to it somewhere.
Slow development
ORM:
(+)
Rapid development
Data access code now under source control
You're isolated from changes in DB. If that happens you only need to update your model/mappings in one place.
(-)
Performance may be worse
No or little control over SQL the ORM produces (could be inefficient or worse buggy). Might need to intervene and replace it with custom stored procedures. That will render your code messy (some LINQ in code, some SQL in code and/or in the DB out of source control).
As any abstraction can produce "high-level" developers having no idea how it works under the hood
The general tradeoff is between having a great flexibility and losing lots of time vs. being restricted in what you can do but having it done very quickly.
There is no general answer to this question. It's a matter of holy wars. Also depends on a project at hand and your needs. Pick up what works best for you.
your question is basically O/RM's vs hand writing SQL
Using an ORM or plain SQL?
Take a look at some of the other O/RM solutions out there, L2S isn't the only one (NHibernate, ActiveRecord)
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
to address the specific questions:
Depends on the quality of the O/RM solution, L2S is pretty good at generating SQL
This is normally much faster using an O/RM once you grok the process
Code is also usually much neater and more maintainable
Straight SQL will of course get you more flexibility, but most O/RM's can do all but the most complicated queries
Overall I would suggest going with an O/RM, the flexibility loss is negligable
LINQ-to-SQL is a remarkable piece of technology that is very simple to use, and by and large generates very good queries to the back end. LINQ-to-EF was slated to supplant it, but historically has been extremely clunky to use and generated far inferior SQL. I don't know the current state of affairs, but Microsoft promised to migrate all the goodness of L2S into L2EF, so maybe it's all better now.
Personally, I have a passionate dislike of ORM tools (see my diatribe here for the details), and so I see no reason to favour L2EF, since L2S gives me all I ever expect to need from a data access layer. In fact, I even think that L2S features such as hand-crafted mappings and inheritance modeling add completely unnecessary complexity. But that's just me. ;-)
There is a whole new approach that you may want to consider if what you're after is the power and performance of stored procedures, and the rapid development that tools like Entity Framework provide.
I've taken SQL+ for a test drive on a small project, and it is really something special. You basically add what amounts to comments to your SQL routines, and those comments provide instructions to a code generator, which then builds a really nice object oriented class library based on the actual SQL routine. Kind of like entity framework in reverse.
Input parameters become part of an input object, output parameters and result sets become part of an output object, and a service component provides the method calls.
If you want to use stored procedures, but still want rapid development, you might want to have a look at this stuff.
Can anyone point out some good LINQ training resources. Mostly interested in getting some developers that are very skilled with SQL up to speed using Lambda and LINQ queries. They are struggling with some of their more advanced queries and fall back on ExecuteQuery() to kind of do the LINQ thing. Queries that used to be easy in TSQL but are now very difficult for them with LINQ.
I can't recommend LinqPad more highly. It's a free Windows app that allows you to use Linq interactively against your data source. It includes tutorials, and allows you to query your data source interactively like you would do in a query analyzer. An excellent resource when trying to make the jump form SQL to Linq.
http://www.linqpad.net/
Pro LINQ should have most of the information they need in chapters 12-15.
I would suggest you look at a utility named Linqer (http://www.sqltolinq.com/). It converts T-SQL to Linq queries. I have found it quite useful at times (I have no relationship with the product).
Also, get LinqPad. This is a must. http://www.linqpad.net/
Randy