Things that are wrong with LINQ (VS2008 .Net 3.5)
A quick list of things that I think are wrong with this first interation of LINQ. Don’t misunderstand me, I am using it right now and it’s working well for me and I’ve not written a single stored procedure. Hooray! I am compiling this in the hope that the LINQ team (Scott Gu?) might find it and do something about it in the next version (or even the next service patch?)
In order of severity of issues:
- Does not easily support N-tier or 3-tier frameworks. It is all in one file, so this is a problem if you want to work with the automatic DataContext generator, AND you want to work with the generated LINQ, AND you want to enforce that all database final actions are performed by the data access layer. To work with native objects in the presentation layer you have to make the whole lot available to every layer, which means potentially any layer could execute a .SubmitChanges(). (I have a work around).
- All multi-row queries return data which contains no public reference to Context. This is what I want to do with LINQ (simplified). DAL generates a small subset of data (an IQueryable object), passes it to the Biz which processes the data and passes it to the UI which modifies the changed data, passes it to the Biz for validation and then is passed to the DAL to be committed to the database. The only way this can happen in LINQ is if you pass the DataContext object along with the data for the entire ride. This is bad (see point 1).
Data retrieved from a query KNOWS what context it has as it is stored in a private variable and will make an exception if you try and save it in a different context. Why not make this private field public or better yet, make it easily Attach to a new context (or possibly with an UpdateOnSubmit)?
-
Using .OrderBy with a GridView.Sorting event is horrible. A beautiful example of how LINQ was never tested in real-world situations. All the 101 samples use non-named, single item arrays to sort. When you hook into a GridView.Sorting event, you are given the SortExpression as a string. So far I have been unable to find a satisfactory way of converting a string into a Lambda expression column. You can use a LinqDataSource control, but then your data access code is in your presentation layer.
Update: There is an MSDN class extender library that allows a lot flexibility with strings. But it’s scope is not wide enough in my opinion. - Visual Data Context generator doesn’t refresh. It is annoying to have to delete all changed objects and re-import them into the diagram.
- Table<TEntity> is sealed. Sealing generally is the DRM of programming. If there is a bug in a sealed class and you want to override it, you’re out of luck. If you have a great idea for a framework and want to inherit from a sealed class, forget about it.
- You have to retrieve rows that you want to delete if you want to use native LINQ. Not enough usage testing I think. If I am using LINQ I do not want to have to form a SQL statement and pass it through, I want to use lambda! LINQ needs a DeleteOnSubmit(lambda expression) that would ignore file queued in InsertOnSubmit().
I appreciate perhaps due to late-loading of data, that the getting the record and then deleteing the record might be optimised to only occur on the DB server, but it’s still a pain. - It’d be nice if the DataContext generator would create a seperate interfaces file. Some frameworks use interfaces to talk between layers and so that external libraries can talk to them as well. All the data objects could quite easily have interfaces defined for them.
The alternative is to use a code-generator to generate interfaces from the database, but then you might as well generate the data context as well.
The list will probably grow as I use it more, but it’s clear that this first version of LINQ has been designed with not many real world tests made of it. The 101 LINQ examples all demonstrate within the same function and most access a single dimensional annonymous array.
Overall it is a great implementation of ORM, and I’m expecting very big things of the next incarnation of it. I think a lot of lessons will be learnt while we struggle away with LINQ 1 for the next few months/years. I just hope we don’t have to wait too long?
