Following on from another question I have just asked...
As much as I love LINQ and other ORM's for speed of development, I am finding that it is actually quiet difficult/impossible/slower (in terms of development speed) to generate complex SQL.
By complex, I mean more advanced SQL such as CTE's, Merge statements, query hints etc...
Can this be done by any existing ORM product? (I have exclusively used MS-L2S)
I am finding more and more than I am resorting to writing the SPROC and calling it through LINQ... Seems to be the best of both worlds at the moment... :/
NHibernate allows you to write native SQL code. I'm sure that this feature should only be used when you really want some complex stuff that the ORM isn't able to handle properly.
Doesn't EF have a similar feature ?
Related
Currently I am using LinqKit / Ms dynamic query example to dynamically build Linq Expressions from strings. This works fine.
LinqKit: http://www.albahari.com/nutshell/linqkit.aspx
Microsoft dynamic Linq queries: http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
Right now, I am migrating my application from C#3.5 to C#4.0. I am wondering if there is another way (standard way of the framework) to build queries from strings.
I have checked the documentation, but did not find anything yet. Also this is not an issue, since I have the above solution.
Only I'd prefer to use the "standard" features if there some. What's the best practice?
I'm currently doing something like this and I'm very happy with the result. The way I did it was with Entity Framework and the ObjectQuery.Select(string query, ObjectParameters[] params) method. More info here: http://msdn.microsoft.com/en-us/library/bb298787.aspx#Y586.
You won't be making expression from string but using SQL to Entities which does the work very well and was made exactly for that purpose as dynamically making Expression isn't trivial and is actually slower.
Cheers
I have not found a clear comparison of what is supported with the NHibernate 3.0 LINQ Provider compared to using the QueryOver syntax. From the surface, it seems like two large efforts into two very similar things.
What are the key trade offs to using each?
LINQ and QueryOver are completely different query methods, which are added to the ones that existed in NHibernate 2 (Criteria, HQL, SQL)
QueryOver is meant as a strongly-typed version of Criteria, and supports mostly the same constructs, which are NHibernate-specific.
LINQ is a "standard" query method, which means the client code can work on IQueryable without explicit references to NHibernate. It supports a different set of constructs; it would be hard to say if there are more or less than with QueryOver.
My suggestion is to learn all the supported query methods, as each use case is different and some work better with one, some work better with other.
I have used both NH-Linq-providers (the old NHContrib for Version 2.1, and also the new for NH3.0) and also used QueryOver. With all the experience made during development of quite complex data-driven applications, I would strongly suggest NOT to use the existing linq-provider with nHibernate if you plan to go behind just basic CRUD-operations!
The current implementation (linq) sometimes produces really unreadable and also unefficient SQL. Especially joining some tables quickly becomes a nightmare if you want to optimize database-performance.
Despite all these drawbacks, I did never encounter wrong queries.
So if you don't care about performance and are already familiar with LINQ, then go for NH-Linq. Otherwise QueryOver is your realiable and typesafe friend.
LINQ to NHibernate (as of version 3.0) does not support the .HasValue property on Nullable types. One must compare to null in queries.
I started to use NH-Linq, because i was already done with LinqToSql and Entity Framework. But, for more complex queries, i have always finished with QueryOver. Reasons:
It's happen that query with NH-Linq doesn't work as expected. I can't remember exactly, but it doesn't work correct with some complex queries. Seems that is too young. And as dlang stated in previous answer, it's produce unefficient SQL.
When you learn QueryOver, it's easy to call functions, do projections, subqueries, seems to me more easy then with NH-Linq.
Good thing for NH-Linq - it can be extended, like Fabio Maulo explained here. But, similar is quite possible with QueryOver, but not so fancy as with NH-Linq :)
I'm looking to learn LINQ, but I'm finding that there is a lot more to it then what I initally expected. In fact, there's so much that I'm not sure where is the best place to start. I know that there's LINQ to SQL, and LINQ to Entities, and a number of other LINQ whatevers out there.
Which is the best to start with? It seems that I see more information readily available about LINQ to SQL, but I have seen quite a bit of information about LINQ to Entities also. Is LINQ to Entities more difficult than LINQ to SQL?
Also, I'm looking for some good resources on learning LINQ. I've seen that Scott Gu has a few blogs on LINQ to SQL, but I'm looking for a little more. Does anyone have a LINQ book that they're impressed with?
LINQ Pad is a good way to start learning, its also free...
http://www.linqpad.net/
I have been looking quite alot for the same, but i have found that there isnt really a place where everything is together..
But there is a few good resources.
LinQ 101 - http://msdn.microsoft.com/en-us/vcsharp/aa336746.aspx
And this one got quite a few small example snippets on how to do things in alot of different languages.
And it got a section for linq too
http://www.java2s.com/Code/CSharp/LINQ/CatalogLINQ.htm
Id say start with linq to sql, they stopped developing that a while back, but the syntax is exactly like linq to entities, linq to entities and linq to sql is almost the same, there is a few things different, but id say start from the "bottom" :)
This is a really good tutorial about how to jump from "linq to sql" to "linq to entities"
http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx
In the beginning, I found Standard Query Operators (MS Word .doc) an invaluable reference.
Pro LINQ by Joseph Rattz is a great book on the subject, although it doesn't cover LINQ to Entities.
As well as in depth examples for each of the standard query operators, it covers:
LINQ to Objects
LINQ to XML
LINQ to DataSet
LINQ to SQL
Although this isn't free, and might seem "daunting" to a beginner. But the Professional LINQ book published by Wrox I found was good as a "get your feet wet" book. It's not what I would consider part of their professional series despite the title and doesn't go into nearly as much depth as it should, but it's a good start nevertheless.
This book/ebook is very good also. Very good for starters.
http://www.manning.com/marguerie/
Here's a great site for practicing it (and also c#).
It still doesn't have LOTS of questions, but there are just enough to get you going (and you can also add questions yourself).
The next best thing to a personal beginner LINQ tutor:
http://www.asp.net/LEARN/linq-videos/
Another good way to learn LINQ is by browsing through code examples, and try them out on your own, if time permits.
Here are two of my personal favorite LINQ resources, which both have easy to understand code examples, and in my view are great for the beginner:
http://linqsamples.com
and
http://www.dotnetperls.com/linq
What are the drawbacks of linq in general.
Can be hard to understand when you first start out with it
Deferred execution can separate errors from their causes (in terms of time)
Out-of-process LINQ (e.g. LINQ to SQL) will always be a somewhat leaky abstraction - you need to know what works and what doesn't, essentially
I still love LINQ massively though :)
EDIT: Having written this short list, I remembered that I've got an answer to a very similar question...
The biggest pain with LINQ is that (with database backends) you can't use it over a repository interface without it being a leaky abstraction.
LINQ is fantastic within a layer (especially the DAL etc), but since different providers support different things, you can't rely on Expression<Func<...>> or IQueryable<T> features working the same for different implementations.
As examples, between LINQ-to-SQL and Entity Framework:
EF doesn't support Single()
EF will error if you Skip/Take/First without an explicit OrderBy
EF doesn't support UDFs
etc. The LINQ provider for ADO.NET Data Services supports different combinations. This makes mocking and other abstractions unsafe.
But: for in-memory (LINQ-to-Objects), or in a single layer/implementation... fantastic.
Some more thoughts here: Pragmatic LINQ.
Like any abstraction in programming, it is vulnerable to a misunderstanding: "If I just understand this abstraction, I don't need to understand what's happening under the covers."
The truth is, if you do understand what's happening under the covers, you'll get much better value out of the abstraction, because you'll understand where it ceases to be applicable, so you'll be able to apply it with greater confidence of success where it is appropriate.
This is true of all abstractions, and applies to Linq in bucketfuls. To understand Linq to Objects, the best thing to do is to learn how to write Select, Where, Aggregate, etc. in C# with yield return. And then figure out how yield return replaces a lot of hand-written code by writing it all with classes. Then you'll be able to use it with an appreciation of the effort it is saving you, and it will no longer seem like magic, so you'll understand the limitations.
Same for the variants of Linq where the predicates are captured as expressions and transported off to another environment to be executed. You have to understand how it works in order to safely use it.
So the number 1 drawback of Linq is: the simple examples look deceptively short and simple. The problem is, how did the author of the sample know what to write? Because they knew how to write it all out in long form, and they knew how pieces of Linq could be used as abreviations, and so they arrived at the nice short version.
As I say, not really specific to Linq, but highly relevant to it anyway.
Anonymous types. Proper ORM should always return objects of 'your' type (partial class, with possiblity of adding my methods, overriding etc.). There are doezne of tutorials and examples of different complex queries using linq but non of them care to explain the advantage of returning a 'bag of properties' (return new { .........} ). How am I supposed to work with anonymous type, wrap it in another class again?
Actually I can´t think of any drawbacks. It makes programming life a lot simpler because a lot of things can be written in a more compact but still better readable way.
But having said this, I must also agree with Jon that you should have some idea what you´re doing (but that holds for all technological advances).
the only drawback which it has is its performance see this article
How easy would it be to write a dumb LINQ provider that can just use my class definitions (which don't have any object references as properties) and give me the translated SQL. It can assume the name of the properties and the columns to be same as well as the names of the classes and the underlying tables. Can you please give me some pointers.?
It took me about 4 months of fulltime work (8 hours a day) to build a stable, working provider that implements the entire spec of linq. I would say I had a very simple, buggy and unstable version after about three weeks, so if you're just looking for something rough I would say you're probably looking at anything from a week up to two months depending on how good you are and what types of requiements you have.
I must point you to the Wayward blog for this, Matt has written a really good walkthrough on how to implement a linq provider, and even if you're probably not going to be able to copy and paste, it will help you to get to grips with how to think when working. You can find Matt´s walkthrough here: http://blogs.msdn.com/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx . I recommend you go about it the same way Matt does, and extend the expression tree visitor Matt includes in the second part of his tutorial.
Also, when I began working with this, I had so much help from the expression tree visualizer, it really made parsing a whole lot easier once you could see how linq parsed to queries.
Building a provider is really a lot of fun, even if a bit frustrating at times. I wish you all the best of luck!
Give a look to the LINQExtender project, is a toolkit for creating custom LINQ providers.
Another option for giving you a leg up seems to be re-linq which is a framework for creating custom LINQ providers.
Here's the Source code and a nice overview (pdf) of what's involved in writing one.
I’ve written a tutorial series on my blog base on my experience developing a LINQ-to-SQL provider from scratch, starting with the expression tree composition stage (calling the LINQ methods), continuing with the expression visitor, breaking down of the query into components, parsing the where clause, generating the text and parameter and, eventually, compiling the whole thing into IL using the .NET expression namespace.
I’ve seen many incomplete posts that promised to explain how to write a provider, falling very short of the mark, barely scratching the surface and not actually delivering anything remotely executable.
The blog series I’ve written based on my experience has a sample project available for download with the simple provider that covers only the functionality required by the tutorial example. However, it also includes the production version supporting a number of operations (where, join, first, count, top, etc.), subqueries, nested statements, and etc. Additionally, it produces a cleaner SQL than a lot of what I’ve seen from Entities and LINQ-to-SQL. There’s no unnecessary/redundant nesting, wrapping everything in brackets and etc.
For anyone with a good level of abstract thinking, developing such a provider isn’t such a difficult task many set it out to be. I’ve developed one that’s used in production environment in about 3 months of part time work (meaning some evenings and weekends). From the get go it was aimed with performance and tidy SQL in mind – a goal it achieved.
It was a little hard to find the time to publish this material, but I thought – if it may help someone out there, there’s no reason for this experience to go to waste:
How to write a LINQ to SQL provider in C# Part 1 - Introduction
How to write a LINQ to SQL provider in C# Part 2 - Expression Visitor
How to write a LINQ to SQL provider in C# Part 3 - Where Clause Visitor
How to write a LINQ to SQL provider in C# Part 4 - Compiling Expression Trees
I have created a project 'LinqToAnything' which is designed to make it very very easy to implement a (simple) Linq provider.