Eric's Blog

Day to day experience in .NET
Welcome to Blogs @ IRM Sign in | Join | Help
 Search

Disclaimer

The content of this site is my own personal opinion and does not in any way represent my employer, it's subsideries or affiliates. These postings are provided "AS IS" with no warranties, and confer no rights.

This Blog

PDC Day Six: Examples of problems that Linq solves

In my first post about Linq, there is a question about real world problems that it solves. Here are some examples:
  1. If you use a OR mapper today you have a couple of problems, for example not always talking as effective as possible with the database (reading to much, making to many calls). With DLinq you will have great ways to do it right.
  2. If you are using OR mappers, you probably also have some kind of Domain Model. When thing that you can do with a DataSet, that is not so easy solved with custom classes is to make queries over the object model. Say that you would like to filter out all order rows that has a value that is greater than a value, or containing products from one product category and so on. This is easily solved with Linq.
  3. Do you do XML programming today? Then you know that it's not as easy as it could be. The new model, not directly coupled to XLinq are easier. The real power of it though is released by combining it with Linq. If you have classes and you want to expose information defined in a Web Service contract, that often is not the same structure as your internal class hierarchy, then Linq will help you a lot on the conversion of these objects to XML messages.
  4. Another scenario could be that you have some data in your database and other data that you have gotten into a XML message by calling a Web Service. If you want to join these two different types of data with each other you will have a really hard time today, but it will be simple with Linq since it is possible to join information from different sources.
Published den 16 september 2005 20:01 by ericqu
Filed under:

Comments

 

Dave Russell said:

Thanks for this Eric.

Since I picked up on LINQ last week I've done some background reading about (X)(D)Linq and I think I have "seen the light" with regards to LINQ. However, I'm not at all sure about DLINQ and XLINQ.

XLINQ

The way I deal with XML today is to use XSD.exe to generate classes using my XSD files. Using the built-in serialisation of .net I can easily generate XML output and read XML input without having to do any XML document processing in my code. This is great because - as you rightly say - manipulation of XML within code isn't ideal.
What I'd like to see from XLINQ is the extension of XSD.exe to include LINQ query functionality within my generated (partial ?) classes. That way I can still use XSD's, still use XML, and still generate my classes automatically, but now I will be able to query my "objects" using LINQ. Fantastic !

I don't want "just-another-xml-document-creator" - even if it is quicker, lighter and easier than the last one. Most of my work is with namespaces and the handling of namespaces within XLINQ is just plain wrong. Why can't we apply a namespace once at a particular node hierarchy point and have it applied to all sub-nodes automatically - without having to append it to every nodes name ?!

DLINQ
"In the real world", most database access (in my experience) is done through Stored Procedures. Usually, the userid accessing the database has no direct table permissions at all. It only has permission to execute SP's. Whether this is right or wrong, in places I have worked it is a widely used security-led practice. The fact that DLINQ appears to only support Stored-procedures in an "afterthought" type way is a big concern to me.
Others have raised issues about it being attribute-led, the extremely basic functionality being offered (compared to other O/R tools) and also the lack of non-SQL-Server support. I see less concern there than the SP issue, which to me is enough to not even consider using it.

Your Examples:

1. Stored Procedure issues outlined above. Also, your "read to much data, make too many calls" argument could be nullified by the lack of indexes being applied to the database tables. I will bow to your knowledge here, though, and assume that just because someone has said they want records for a particular criteria that their query isn't translated directly to a "WHERE" clause that doesn't make use of an index on the applicable table(s). I'll assume some clever code identifies which index is best to use and filters the remaining records in code before they are returned to the caller.......rather than causing full-table-scans....?

2. "Filtering out all order rows that has a value that is greated than a value" isn't something that I can't do before having LINQ. I can do this in SQL. So I don't get why it's suddenly going to be better?

3. Using XLINQ to create documents using class-properties is a good one. I see that XLINQ provides better support for this. However, my point above still stands (re XSD.exe).

4. LINQ will be useful for this I agree.

Summary:

LINQ - I like the idea of this.
XLINQ - Promising, but needs more work.
DLINQ - Won't even consider using it until SP support is integral. Or are MS suggesting we review our security models?
september 19, 2005 12:08
 

ericqu said:

The four examples that I provided was just some quick ideas that I wrote down during a PDC session and I must say that I have definitely not have had the time to let the complete LINQ picture fall in place. It might even be so that you have hade more time to read up and think about it, but still my impression last. It seems to be a very attractive and useful feature when developing applications and you seems to get to the same conclusion. I don’t think that everyone will use all aspects of the LINQ project, as I understand it you don’t either.
For your big concerns about XLINQ and DLINQ I will just make some short comments. If you are using XSD to generate classes and this is a successful solution for you I think that you should continue with that and would therefore only use LINQ and not XLINQ. But there are not always possible to use XSD.exe and I truly believe that XLINQ will fill some gaps and make it easier to work with “raw” XML.
Today I always use SP for all data access and I do not use any OR mappers today and I don’t create domain models (generally speaking). But many of my arguments for not using OR mappers and domain models becomes a lot weaker when LINQ and DLINQ arrives and two of them is 1 and 2 in the original post. As far as I can tell DLINQ (I don’t think it’s only for SQL Server, but actually a big part of ADO.NET 3 no matter which DB) does a much better job than today’s OR mappers, because it seems to create better SQL. Another problem that I have with the creating a domain model with classes is that it will take a lot of time to filter, sort and query the objects (2) something that LINQ solves. Of course I do this a lot in SQL, but quite often it is also necessary to do it later on, for example on the client without requiring a new question to the database.
I definitely think that you are correct with your concerns about the lack of support for SP:s and that will cause many organisations to not even consider using DLINQ, but then again, many other organisations sees the database as a storage for their objects and nothing more (I don’t).
I think that the LINQ project looks great and that we should give Microsoft a lot of feedback and let them know what our concerns are. I have more concerns than the examples that you brought up here, but I still think that the features provided will be very useful for most programmers and for some all the time. As I also wrote in my original post, I’m definitely willing to rethink the way I develop today, because of LINQ. What the result and conclusion of my rethink will be, I actually can’t say today, because I have only seen a very early technology preview, which probably will change many times before it is released. The future will tell and it’s exciting :).
september 22, 2005 11:39
New Comments to this post are disabled
Powered by Community Server, by Telligent Systems