As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Are there any good Reasons not to use LINQ in my projcts? We use .Net 3.5 and VSTO 3.0.
Personally I can't see why you wouldn't want to use it, it makes code much more readable.
With that being said, LINQ can sometimes be detrimental to performance in certain scenarios, that would really only be my reason for not using it.
The other answers have implied this, but here it is explicitly:
The term "LINQ" can refer to the overall set of technologies for Language INtegrated Query. These technologies permit a LINQ Query to be turned into an expression tree. That tree can be executed at a later time, by a "LINQ Provider".
The LINQ Provider looks at the expression tree and converts it into, for instance, SQL statements, or XML DOM navigation, or navigation through an object graph. These providers have names like "LINQ to SQL", "LINQ to Entities", "LINQ to Objects", etc.
There could be reasons to not use a specific provider.
Many of the individual LINQ providers come with additional tooling (some would say, "baggage"). This tooling helps provide some of the most common "pros and cons" about LINQ.
In particular, LINQ to SQL provides a direct, one to one mapping to the database schema. Each LINQ class corresponds to a single database table. If the structure of the database changes, then so does the code. This can be mitigated to an extent by using views.
I believe that LINQ to SQL is limited to Microsoft SQL Server. Also, Microsoft has stated that LINQ to SQL will not be a priority investment going forward.
LINQ to Entities is part of the ADO.NET Entity Framework (EF). EF provides for modeling your entities in a more abstract, conceptual level. For instance, you might have a Person entity that takes data from two tables that have a one to one mapping. Code accessing this entity need not care how the tables are broken out in the database.
I believe that LINQ to Entities is meant to work with many ADO.NET providers, not just SQL Server. Also, this is where Microsoft says it will be placing its investments going forward.
In both of these cases of LINQ to "some database", it's almost always going to be the case that a experienced SQL developer and/or DBA can write better queries than will be generated by LINQ. If performance is the top requirement, I believe that LINQ to Entities can map stored procedures into methods on the entities.
The big benefit of these LINQ providers is that you don't need that experienced SQL developer or DBA when you're working in an environment where performance is not the top priority. This frees them up to optimize queries that actually require their expertise.
Another reason not to use these directly is if you have security considerations preventing your users from having SELECT permissions to the database tables. In that case, use views or stored procedures.
Yes, there are reasons. I'm going to talk about some of the difficulties I've faced when using various LINQ providers for RDBMS.
LINQ works great in most cases, but when you want to build complex queries (e.g. in reporting apps) it's statically-typed nature becomes a disadvantage. It's hard to, for instance, conditionally JOIN, or conditionally GROUP BY, because the result type changes, even if in the end you want to project the same fields. It's also hard to do LEFT JOIN. If you really appreciate dynamic queries then SQL and ESQL are better options.
Also, the same LINQ query can be (and usually is) interpreted differently depending on the provider, which can lead to unexpected results when switching providers.
About SQL functions, not all the functions you need are mapped to CLR methods, and not all providers offer a extensibility mechanism for mapping functions.
Finally, the performance issue. Converting expression trees to store queries can be expensive, and sometimes the end result is not the best possible query. The most elegant source code is not always the best runtime code.
The only reason would be if you have a very performance critical app as LINQ to Objects queries usually perform worse than for loops. This will change with .Net 4.0, when you can make use of PLINQ's parallel processing features.
Anyhow, if you have such a performance critical app, you probably should not use a managed environment anyways. in 99% of all cases LINQ will make your code more readable and more elegant. It's deferred execution mechanism may even gain you some performance under the right circumstances.
Well, if you want to make a step backwards and work 2xtimes longer on your projects you shouldn't use it ;-)
I think there is no real good reason to NOT use it. You are faster, smarter and you can make less mistakes and have more control since you can work "datatyped"
In a very short answer: no, there is no reason not to use Linq. Although it can be slightly hard to grasp for people new to the concept of functional programming (but only slightly), once you get the hang of it, you will love it, and it can in general greatly improve the readability of the code.
It depends on whether you're referring to LINQ to SQL or LINQ as a modelling tool. Personally I use LINQ for modelling only because my superiors who are actually less educated than me in this area refuse to it for a number of reasons. One reason is that they've stopped adding new features completely and are only maintaining bug fixes in LINQ now. Secondly is that it's supposedly slower than direct SQL, which to a certain degree is true when running lower end hardware perhaps, I don't know. Thirdly is a domain perspective, if you want to shy away from SQL injection vulnerabilities supposedly it's wise to use stored procedures instead. In all instances for us, we use LINQ for modelling only now, stored procedures are "compiled" on the server after being run for the first time.
Personally I just meet requirements, I have no powers for decision, but LINQ is great for modelling and includes many handy features.
The LINQ architecture is good - but some may prefer to read source code that does not use the LINQ SQL-like syntax. So if you're strict on readability, you may want not to use that syntax.
I have encountered some issues with it that I've had to work around. For example, depending on how your database relations are setup you may find that linq2sql works great for querying, but has trouble updating correctly. This happened to me and what I did was setup two sets of linq objects. The first had all the relationships I needed so I could use simpler syntax for querying, but the second didn't contain the relationships for when I wanted to update since I didn't need them then.
Performance shouldn't be a reason not to use it because generally that's only an issue for certain processes. And it's not like you have to use linq exclusively or not at all. I think a lot of people think "oh, direct sql is faster and there are some things I need to do that HAVE to be fast so I can't use linq". That's just silly though. Use it where you can, and use direct sql where you can't.
What I can figure out from various posts is that it depends on requirement
LINQ works independent of datasource ....work on file objects and database in same way
LINQ can reduce multiple queries into one
LINQ has the type safety
Overall good to use and faster development
LINQ still has a lot of open issues
LINQ has stopped evolving (nothing new coming up)
SQL is more reliable and more efficent
SQL is better when working with more complex queries, stored procedures
SQL is faster then LINQ-SQL
So depending on if your project requires inline queries not so complex and involves to query data sources other then relational database like SQL use LINQ otherwise go for good old SQL server.....:)
not to use LINQ if you mean LINQ as "LINQ to SQL" and your SQL Server has performance problem with a Adhoc Query Execution.
As for me - only one reason not to use LINQ. It is third-party enhancement tools for this product. I prefer - Devart LinqConnect, for example.
LINQ is a great technology, but produce a uggly code. If you thinking, you are a Picasso of code don't use it.
Produce code without LINQ is producing readable code. But i use always ;)
Yes, definitely makes things more readable and concise. Certainly did for the 15 years I used it in Visual FoxPro ;)
Related
I noticed that if I specify a constant in an EF query that the value gets inlined, but if I specify that same value as a variable then EF creates a subquery for it and passes it in as a parameter. Are there any performance differences between the two approaches?
I have some massive Linq queries and I'm wondering if using constants might help with performance in terms of both the query execution (and plan caching) and in the translation from Linq to SQL.
I suggest you check out this article from TechNet:
https://technet.microsoft.com/en-us/library/ms175580(v=sql.105).aspx
It states that if you use literals, then the query optimizer should recognize it, but sometimes it might not.
The only difference between the execution plans for these queries is
the value stored for the comparison against the ProductSubcategoryID
column. While the goal is for SQL Server to always recognize that the
statements generate essentially the same plan and reuse the plans, SQL
Server sometimes does not detect this in complex SQL statements.
Note the words "complex" and "sometimes" — quite a concrete explanation, isn't it? :)
The article also goes on to explain that if you use parameters, it "helps" the engine to reuse plans (again, concrete), some things about simple parameterization and forced parameterization.
So the documentation says that it is not certain, but usually this should not make a difference. As or my own experience: I've found that the engine is able to recognize the constants in queries generated by EF quite well. I had the same question a while back, and did some checking on Azure SQL. I wouldn't say I examined the most complex generated SQL queries of the world, but they were not just simple select-where-let-join combos.
But again, that was for my queries in a specific version of the engine. To be sure, I would suggest you also check your queries in question, and then you can be sure.
I'm working on porting an old application to from WebForms to MVC, and part of that process is tearing out the existing data layer, moving the logic from stored procedures to code. As I have initially only worked with basic C# SQL functions (System.Data.SqlClient), I went with a lightweight pseudo-ORM (PetaPoco), which just takes a SQL statement as a string and executes it. Building dynamic queries would work about the same in SQL - lots of conditionals that add and remove additional code (average query has ~30 filters).
So after looking around a bit, I found some choices:
A bunch of strings and conditionals that add bits of the query as they are needed. Really nasty, especially when queries get complex, and not something I want to pursue if a better solution exists.
A bunch of conditionals using L2E. Looks more elegant, but I tested L2E is too bloated in general was an awful experience. Could I do the same thing in L2S? If so, is L2S going to stick around for the next 5-10 years?
Use a PredicateBuilder. Still looking into this, same questions regarding L2S.
EDIT: I can also just stick to the existing stored procedure model, but I have to rewrite them anyway, so it can't hurt to look at other options as I'm still going to have to do the leg work.
Are there any other options out there? Can anyone weigh in with some experience on any of the mentioned methods - mainly, did the method you choose make you want to build a time machine and kill past you for implementing it?
I'd look at LLBLGen. The code that it generates is quite good and customizable. They also provide a robust linq provider which may help with your queries. I used it for a couple large projects and was quite happy.
http://www.llblgen.com/
In my opinion, neither L2S nor L2E can generate efficient SQL code, especially when it comes to complex queries. Even in some relatively simple cases generating queries via either of the two methods would yield inefficient SQL code, here's an example: Why does this additional join increase # of queries?
That being said, if you're using SQL Server L2S is a better option, as L2E is meant to handle any database; Because of which L2E will generate inefficient SQL code. Also another point to keep in mind is neither L2S or L2E will leverage the tempDB, i.e. generating temp-tables or table variables or CTEs.
I would re-write the stored procedures, optimizing them as much as possible, and use L2S/L2E for simple queries, that would generate one round-trip (this should be as low as possible) to the server, and also ensure that the execution plan SQL Server uses is the most efficient (i.e. uses indexes etc).
Hasanain
Not really an answer, but too long for a comment:
I have built a mid-sized web app using the 'concatenate pieces of SQL' method, and am currently in the process of doing a similar job but using L2E.
I found that with some self-control, the concatenate-pices-of-sql method is not that bad. Of course use parameterized queries, don't try to stick user input into the SQL directly.
I have been slowly growing an appreciation for the L2E method though. It gives you type safety, though you do have to do some things "backwards" from how you might do it with SQL -- such as WHERE X IN (...) constructs. But so far I haven't hit anything that L2E can't handle.
I feel like the L2E approach would be a little easier to maintain if other people were to be heavily involved.
Do you have actual use cases where the "bloat" of L2E is a problem? Or is it just a general sense of malaise where you feel the framework is doing too much behind the scenes?
I definitely had that feeling at first (ok, still do), and certainly don't like reading the generated SQL (esp. compared to my handwritten SQL from the previous project), but so far have found L2E pretty good with regard to only hitting the DB when it is actually necessary.
Another concern is what DB you're using, and how up-to-date its L2E bindings are. If you're using SQL Server, then no problem. MySql might be more flaky though. A chunk of L2E's slickness comes from its nice integration with VStudio, and VStudio's ability to build entity models from your DB automagically. Not sure how good the support is for non-MS DB backends.
I ultimately have two areas with a few questions each about Entity Framework, but let me give a little background so you know what context I am asking for this information in.
At my place of work my team is planning a complete re-write of our application structure so we can adhere to more modern standards. This re-write includes a completely new data layer project. In this project most of the team wants to use Entity Framework. I too would like to use it because I am very familiar with it from my using it in personal projects. However, one team member is opposed to this vehemently, stating that Entity Framework uses reflection and kills performance. His other argument is that EF uses generated SQL that is far less efficient than stored procedures. I'm not so familiar with the inner-workings of EF and my searches haven't turned up anything extremely useful.
Here are my questions. I've tried to make them as specific as possible. If you need some clarification please ask.
Issue 1 Questions - Reflection
Is this true about EF using reflection and hurting performance?
Where does EF use reflection if it does?
Are there any resources that compare performance? Something that I could use to objectively compare technologies for data access in .NET and then present it to my team?
Issue 2 Questions - SQL
What are the implications of this?
Is it possible to use stored procedures to populate EF entities?
Again are there some resources that compare the generated queries with stored procedures, and what the implications of using stored procedures to populate entities (if you can) would be?
I did some searching on my own but didn't come up with too much about EF under the hood.
Yes, it does like many other ORMs (NHibernate) and useful frameworks (DI tools). For example WPF cannot work without Reflection.
While the performance implications of using Reflection has not changed much over the course of the last 10 years since .NET 1.0 (although there has been improvements), with the faster hardware and general trend towards readability, it is becoming less of a concern now.
Remember that main performance hit is at the time of reflecting aka binding which is reading the type metadata into xxxInfo (such as MethodInfo) and this happens at the application startup.
Calling reflected method is definitely slower but is not considered much of an issue.
UPDATE
I have used Reflector to look at the source code of EF and I can confirm it heavily uses Reflection.
Answer for Issue 1:
You can take a look at exactly what is output by EF by examining the Foo.Designer.cs file that is generated. You will see that the resulting container does not use reflection, but does make heavy use of generics.
Here are the places that Entity Framework certainly does use reflection:
The Expression<T> interface is used in creating the SQL statements. The extension methods in System.Linq are based around the idea of Expression Trees which use the types in System.Reflection to represent function calls and types, etc.
When you use a stored procedure like this: db.ExecuteStoreQuery<TEntity>("GetWorkOrderList #p0, #p1", ...), Entity Framework has to populate the entity, and at very least has to check that the TEntity type provided is tracked.
Answer for Issue 2:
It is true that the queries are often strange-looking but that does not indicate that it is less efficient. You would be hard pressed to come up with a query whose acutal query plan is worse.
On top of that, you certainly can use Stored Procedures, or even Inline SQL with entity framework, for querying and for Creating, Updating and Deleting.
Aside:
Even if it used reflection everywhere, and didn't let you use stored procedures, why would that be a reason not to use it? I think that you need to have your coworker prove it.
I can comment on Issue 2 about Generated EF Queries are less efficient than Stored Procedures.
Basically yes sometimes the generated queries are a mess and need some tuning. There are many tools to help you correct this, SQL Profiler, LinqPad, and others. But in the end the Generated Queries may look like crap but they do typically run quickly.
Yes you can map EF entities to Procedures. This is possible and will allow you to control some of the nasty generated EF queries. In turn you could also map views to your entities allowing you to control how the views select the data.
I cannot think of resources but I must say this. The comparison to using EF vs SQL stored procedures is apples to oranges. EF provides a robust way of mapping your Database to your code directly. This combined with LINQ to Entity queries will allow your developers to quickly produce code. EF is an ORM where as SQL store procedures is not.
The entity framework likely uses reflection, but I would not expect this to hurt performance. High-end librairies that are based on reflection typically use light-weight code generation to mitigate the cost. They inspect each type just once to generate the code and then use the generated code from that point on. You pay a little when your application starts up, but the cost is negligible from there on out.
As for stored procedures, they are faster than plain old queries, but this benefit is often oversold. The primary advantage is that the database will precompile and store the execution plan for each stored procedure. But the database will also cache the execution plans it creates for plain old SQL queries. So this benefit varies a great deal depending on the number and type of queries your application executes. And yes, you can use stored procedures with the entity framework if you need to.
I don't know if EF uses reflection (I don't believe it does... I can't think of what information would have to be determined at run-time); but even if it did, so what?
Reflection is used all over the place in .NET (e.g. serializers), some of which are called all of the time.
Reflection really isn't all that slow; especially in the context of this discussion. I imagine the overhead of making a database call, running the query, returning it and hydrating the objects dwarf the performance overhead of reflection.
EDIT
Article by Rick Strahl on reflection performance: .Net Reflection and Performance(old, but still relevant).
Entity Framework generated sql queries are fine, even if they are not exactly as your DBA would write by hand.
However it generates complete rubbish when it comes to queries over base types. If you are planning on using a Table-per-Type inheritance scheme, and you anticipate queries on the base types, then I would recommend proceeding with caution.
For a more detailed explanation of this bizarre shortcoming see my question here. take special note of the accepted answer to that question --- this is arguably a bug.
As for the issue of reflection -- I think your co-worker is grasping at straws. It's highly unlikely that reflection will be the root cause of any performance problems in your app.
EF uses reflection. I didn't check it by I think it is the main point of the mapping when materializing instance of entity from database record. You will say what is a column's name and what is the name of a property and when a data reader is executed you must somehow fill the property which you only know by its name.
I believe that all these "performance like" issues are solved correctly by caching needed information for mapping. Performance impact caused by reflection will probably be nothing comparing to network communication with the server, executing the complex query, etc.
If we talk about EF performance check these two documents: Part 1 and Part2. It describes some reason why people sometimes think the EF is very slow.
Are stored procedures faster then EF queries? My answer: I don't think so. The main advantage of the linq is that you can build your query in the application. This is extreamly handy when you need anything like list filtering, paging and sorting + changing number of displayed columns, loading realted entities etc. If you want to implement this in a stored procedure you will either have tens of procedures for diffent query configurations or you will use a dynamic sql. Dynamic sql is exactly what uses EF. But in case of EF that query has compile time validation which is not the case of plain SQL. The only difference in performance is the amount of transfered data when you send whole query to the server and when you send only exec procecdeure and parameters.
It is true that queries are sometimes very strange. Especially inheritance produces sometimes bad queries. But this is already solved. You can always use custom stored procedure or SQL query to return entities, complex types or custom types. EF will materialize results for you so you don't need to bother with data readers etc.
If you want to be objective when presenting Entity framework you should also mention its cons. Entity framework doesn't support command batching. If you need to update or insert multiple entities each sql command have its own roundrip to database. Because of that you should not use EF for data migrations etc. Another problem with EF is almost no hooks for extensibility.
I've heard from some that LINQ to SQL is good for lightweight apps. But then I see LINQ to SQL being used for Stackoverflow, and a bunch of other .coms I know (from interviewing with them).
Ok, so is this true? for an e-commerce site that's bringing in millions and you're typically only doing basic CRUDs most the time with the exception of an occasional stored proc for something more complex, is LINQ to SQL complete enough and performance-wise good enough or able to be tweaked enough to run happily on an e-commerce site? I've heard that you just need to tweak performance on the DB side when using LINQ to SQL for a better approach.
So there are really 2 questions here:
1) Meaning/scope/definition of a "Lightweight" O/RM solution: What the heck does "lightweight" mean when people say LINQ to SQL is a "lightweight O/RM" and is that true??? If this is so lightweight then why do I see a bunch of huge .coms using it?
Is it good enough to run major .coms (obviously it looks like it is) and what determines what the context of "lightweight" is...it's such a generic statement.
2) Performance: I'm working on my own .com and researching different O/RMs. I'm not really looking at the Entity Framework (yet), just want to figure out the LINQ to SQL basics here and determine if it will be efficient enough for me. The problem I think is you can't tweak or control the SQL it generates...
When people describe LINQ to SQL as lightweight, I think they mean it is good enough at what it does, but there is a lot of stuff it doesn't even try to do. I think this is a good thing, because all that extra stuff that other ORMs might try to let you do isn't really even needed if you're just willing to make a few sacrifices.
For example, I think it's a best practice to try to keep all application data in a single database. This is the kind of thing that LINQ to SQL expects if you want to be able to do Joins and whatnot. However, if you work in some environment with layers of bureaucracy, you might not be able to convince everyone to move legacy data around, or centralize on a single way of doing things. In the end you need a more complicated ORM and you end up with arguably crapper software. That's just one example of why you might not be able to shape that data as it needs to be.
So yeah, if big .com's are willing or able to do things in a consistent manner and follow best practices there is no reason why the ORM can't be as simple as necessary.
Just wondering whether anyone will still use Hibernate once they move to C# 3
Are these mutually exclusive??
It's important to note that Linq is not just an ORM tool. There is also Linq-To-XML and Linq-To-Objects to name two but there are more. Linq is a set of language extensions to C# and VB that give you syntactic sugar when dealing with object collections.
As to your main question, Linq-to-SQL is fine if you have a one-to-one mapping from tables to domain objects. Where NHibernate comes into it's own is where you have an existing complex domain model or existing complex database schema and you want to map between them.
Additionally, it's possible to use both with Linq-To-NHibernate.
Linq is more about making a uniform way in which one can query DB, XML, Objects or any custom data store. Hibernate is only for querying DBs.
You can use Hibernate instead of Linq-to-SQL in case you are more proficient and comfortable in that Linq provides pretty much the same powerful ways to query DB as Hibernate. So in a way when restricting our discussion to DB, Linq can serve you the same (or a large majority of!) purpose as Hibernate.
I think more people would use NHibernate if it could compete with Hibernate. That being said, NHibernate is generally not needed in a .net shop.
The existance of Linq To NHibernate alone, proves not.
Your terminology is off. LINQ is just syntactic sugar for manipulating data. Linq to Sql is probably what you're talking about.
IIRC Linq to Sql only supports MSSql (apparently they intentionally killed off compatability with other db providers, I have no idea why, some speculate anti-competition, others state a deadline turned up so they just culled what wasn't ready). So no chance of NHibernate being irrelevant here.
The Entity Framework (MS's ORM tool that supports all databases). When this initially came out some of the ORM community hated it, it didn't support "persistence ignorance" and a number of features, concepts and premises the community expects from a modern ORM. I believe they are working to improve it but they have a lot of catching up to do to get close to NHibernate IMO.
So no, NHibernate is still massively relevant if you want fine control over your ORM. It is one of the most flexible yet complex ORMs about and therefore still has its place.
I dont like linq-to-sql (since that is what you mean) that much since you have to design a database schema. With hibernate (although i use a similar product named XPO) you just make your objects and the framework takes care of the relations (one-to-one, many-to-one, M-To-M).
THat is the big disadvantage of linq to sql. So no, they're not mutually exclusive.