Are there any plans to include LINQ support for WebData?
i.e.
NorthwindWebDataContext ctx = new NorthwindWebDataContext(...); var q = from c in ctx.Customer where c.City == "London" select c;Code Snippet
instead of
WebDataContext ctx = new WebDataContext(...); var custs = ctx.CreateQuery("/Customers[City eq 'London']");Code Snippet
That would be sooo cool
Best regards
Torsten Seemann
Hi Torsten,
Yes, we have been experimenting with the idea of supporting LINQ on top of the client library, and we have a working proof of concept.
The main challenge is that the class of queries that you can express with LINQ is much broader than the one we can represent with Astoria URIs. The effect is that there will be many queries that will result in a "not supported" exception. The patterns can be clearly documented so you know when a query will work and when it won't, but the net effect is that the experience is not completely seamless.
I'd be curious to know if you think this is an acceptable story (restricted LINQ queries).
Thanks,
Pablo Castro
Technical Lead
Microsoft Corporation
Hi Pablo,
I understand your concern about not being able to support the complete query capabilities of LINQ. In my opinion though, the benefits of clearer expressions, type safety and intellisense far outweighs the fact that some queries may not be supported. As long as all Astoria query types are supported by LINQ I will be happy
What are your thoughts on using Entity Framework in n-tier solutions with rich clients? Would you recommend "hiding" the EDM in a middle-tier and use another object model in the client tier or is there some way to reuse the EDM on both tiers? I kinda see the Astoria client library as a way of making the EDM available on both tiers, but I might be wrong.
Regards
Torsten
I've been doing some thinking about this myself. While I think it's a nice idea that I should be able to go directly to my remote Web Data source (Astoria service) and run a LINQ query on the remote source... the more I think about it the more I think it might actually be somewhat impractical to do so. Mainly for the reasons that Pablo already suggested - the types of queries that you can express with LINQ are far more complex than what you can get via Astoria URI syntax.
What I have been doing up to this point is hitting the Astoria service for the raw data using the client library, getting something that supports IEnumerable, and then doing my complex stuff like grouping after the fact (and in-memory) using LINQ then. While it might seem like "more" work, it's actually only one extra line of code, and the tradeoff there is I have explicit control over the amount, size, and shape of data going across the wire. While I don't normally need this kind of thing when doing LINQ to SQL (my client is on the same backbone network as my SQL Server) ... when my client is on the internet somewhere, and my server is on the internet somewhere, and I can't control the quality, bandwidth, or reliability of that connection, I much prefer having rigid control over what information is transferred, and then I can do the fancy LINQ stuff later.
In short, if I want to do a LINQ group by to populate a nice expand-collapse tree control on the client, rather than issue LINQ to WebData queries against the server and run the risk of it making multiple repeated network calls to facilitate my "data shaping" request, I would much rather issue a request for the raw data that I know I'm going to need, filtered accordingly. Then I can simply group my results using an in-memory LINQ query after that.
One of the worst things a tool library can ever do is attempt to be more than it should be and do more things than it should. I personally don't think there is enough benefit of having the Astoria web data client support LINQ to merit it's inclusion, but that's just my two cents
I'd have to disagree with Kevin, since when I query for something I am primarily interested in the end result. A LINQ wrapper for Astoria should simply be able to perform any local processing for me by splitting the original query into a remote data-fetch operation and a local data-transformation operation. This should be possible as the criteria for what goes where is simple: whatever the remote end can do, it should do. Whatever it cannot must be done locally.
Having such a LINQ front-end would take Astoria from being a speciality product to being something truly useful for many more developers, and make interacting with the data much more seamless and type-safe to boot.
I've heard arguments for both perspectives; the one that says that we should be completely explicit and the one that says that if the system knows how to satisfy a request it should do it regardless of the efficiency impact.
My personal take based on experience designing APIs for a while is that explicitness is a good thing. For large customer bases it's hard to predict what developers will use the APIs for and what assumptions they'll make. Furthermore, explicit makes it less likely that you build and test a system with certain data-set and it works, and then once deployed a different set of inputs changes the system behavior so dramatically that it becomes unusable; if that is due to magic done by the system to compensate for lack of capabilities in some underlying piece, it is very hard to troubleshoot and fix.
That is not to say that you won't be able to write sophisticated LINQ queries when using the Astoria client API. What is means that what we'll probably do is to make it explicit (e.g. fail) when we cannot translate a query if you are querying directly against the server. Since we return objects, you can always say ".AsEnumerable()" at the end of the server-side query and then write a query on top of that which can be as complicated as needed, as that one will be processed by the default LINQ library in-memory.
Pablo Castro
Technical Lead
Microsoft Corporation
If and when Astoria talks to LINQ, it'll be a useful product. All the time it talks to ADO.NET, it'll be a solution looking for a problem in my view.
Hi David,
Could you describe in more concrete terms why do you think that using ADO.NET to access the data to served through Astoria services will not be interesting? I'm curious to understand what are you concerns around that design point; whether it is that your data sources typically don't have ADO.NET providers, or that they are not databases all together, or that you are thinking about some specific limitation of ADO.NET that I didn't think about.
Regarding the LINQ way of doing things, stay tuned to the Astoria blog (http://blogs.msdn.com/astoriateam), we'll post the design notes that describe the system layering in a week or so and it'll include a discussion about this as well (and my guess based on your comment is that you'll be happy with what you see...)
Pablo Castro
Technical Lead
Microsoft Corporation
Pablo,
My gut feeling is that a framework will emerge that will, by fixing on a specific WCF contract, enable a broad class of LINQ queries to be transmitted over HTTP. That framework will likely need awareness of the entities being queried; indeed it will closely resemble Astoria.
In the post-LINQ world, frameworks without such power will feel somewhat quaint. Altogether, my gut tells me that Astoria should support broad LINQ.
There is no technical limitation preventing you from taking a rich query in the request body. What are your reservations?
This is a good observation. I agree that people are trying to pass arbitrary queries (in the form of LINQ expressions) across tiers using WCF. What I don't agree is that it's a good thing to do.
I guess the simplest way to articulate my reservation is: how is that different from just opening direct query access to your database? or from taking a SQL statement? In the end, an expression tree or a SQL query are just two -of many- representations for a query.
One argument I heard a few times is that this is different because the middle-tier could look at the LINQ expression tree and apply business logic based on that to restrict which queries are allowed or to re-write/adapt the queries as needed. I've been working on LINQ implementations for quite a bit of time now (since the very beginning) and was one of the members of the team that did LINQ to Entities and LINQ to DataSet. I can tell you that analyzing LINQ queries is an extremely hard problem because of the broad expressivity of the expression trees (pretty much most of the C#/VB languages). The same query can be expressed in so many ways, and there tends to be so much language noise in them, that the task is almost impossible with introducing a set of restrictions (and still it’s a hard thing to implement).
LINQ expression trees are the way they are for a good reason. But I see them more as a system level tool than something you regularly deal with in application code. In my opinion application code needs to deal with simpler constructs that are closer to the concepts the application is modeling.
That’s why in Astoria we restrict the class of queries you can exchange to those we can express in terms of simple operations on resources (entities). You can do key-based lookups, property access (which becomes association traversal for navigation properties) and a few operations on the leaf set (filter, sort, page). Those are things that we can elevate to simple events/callbacks that user code can run in. They are also simple enough that is possible to describe declarative policies on top.
I don’t think Astoria will solve all the scenarios for middle-tiers or come even close. I do think, however, that between Astoria and a more structured style of use of WCF with strict contracts will cover most of the spectrum that I consider the reasonable way of building componentized applications. The end of the spectrum that’s not handled by these technologies, where arbitrary queries are exchanged between components that have a coupling/trust/design boundary in-between is not supported almost by design…
Pablo Castro
Technical Lead
Microsoft Corporation
Pablo,
You make a good point about restricting the allowed queries. I wonder if enough power is in the LINQ-to-SQL data model definition to suffice. In other words, my client tier can query over anything in such-and-such data model, which might not be the same model as what is used elsewhere. The data model would represent a specific contract.
Facebook's new platform offers an interesting example. They offer a web service with which you can issue Facebook-Query-Language (FQL) queries. The queries execute in the context of a specific user, and the results are constrained automatically. This is quite sophisticated and powerful. Now imagine how such context (session) information might be injected into an expression tree, or passed out-of-band somehow to underlying SQL views.
The wisdom of allowing free-form queries, as Facebook has done, is to mitigate the need for a huge list of overloaded service methods.
