UI-determined data needs via LINQ?

Question

Bravo to the C# team for making a language like LINQ a first-class language-extension with all of Microsoft's tools behind it, this really is revolutionary.

It seems that LINQ's lambda expressions offer ASP.Net pages a major new opportunity:
1) Set a Datasource for all controls on the page
2) Let controls simply ask for data as though they were accessing object properties
3) The ASP.Net engine could take the following steps:
a) Create a LINQ expression for each data request (some requests may be defined already as LINQ expressions)
b) Perform a somewhat trivial step of optimizing the set of queries - LINQ's high-level nature makes it simple to notice, for example, that 5 controls are each getting a different field all from the same table with the same sort and filter. These could be merged to one LINQ statement asking for those 5 fields, obviously.
c) Fetch and feed that data to the controls.

This eliminates all data calls - no creation of Data Transfer Object classes, no creation of Data Access code, not even .DataBind() calls - just a UI that asks for data. That would be a major step forward and LINQ really opens that door.

Answer 1

This is an interesting proposition.  You are basically suggesting that the data-binding technology gather all requests and form a projection dynamically.  I think someone can at least turn it into a sample. 

We did think along these lines early in the project.  We were also imagining that the language compiler could simply deduce from data used in the program which actual fields were needed and infer the proper projection automatically.  It turns out to be very complicated to do this.  UI data binding does simply the problem.

 

Answer 2

Thank you for the interest!

Yes, some thought would have to be paid to "Automatic on/off" per se. For example, this free data-fetch functionality might be only available to controls inside a specific tag - maybe a tag called, DataSource. That way if the code-behind wants to do more complex data fetching of its own, it's free to, and you aren't caught in the bind you mentioned of trying to parse code-behind (and attached classes) to optimize data calls.

There is a minor issue of how best to turn this on or off for a given databound tag, that lies in the tag-based nature of ASP.Net. HTML tables still struggle with this issue (we can do rows, but how do we do columns?). The decision to have implied data is essentially a secondary axis to the flow of tags on the page. The way HTML tables solve this is one way (the same way ASP.Net's Validation controls are done), but it's very wordy. Perhaps offering both covers all the bases:

Case 1:
<asp:DataSource DataSource="MySchema.Customers">
<asp:Repeater>
<ItemTemplate><%# SomeCustomerProperty %></ItemTemplate>
</asp:Repeater>
. . .
</asp:DataSource>

Case 2:
<asp:DataSource DataSource="MySchema.Customers" Controls="Repeater1, Repeater2">
<asp:Repeater id="Repeater1">
<ItemTemplate><%# SomeCustomerProperty %></ItemTemplate>
</asp:Repeater>
. . .
</asp:DataSource>

Answer 3

It may interest you to know that Scott Guthrie mentioned the upcoming LinqDataSource in his blog recently.  He didn't provide any details.  But yes, the DataSource model is cool.

Answer 4

That's fitting, although if Microsoft is being as excellently consistent as they've been with much of the .Net Framework's naming conventions, that sounds more like a datasource you pass LINQ commands to than a UI parser for a tag that aggregates the data calls its child tags are making, optimizes them in LINQ, then passes them to - for example - a LinqDataSource object to be translated into datasource-specific calls (SQL, DOM, etc).

Answer 5

hmmmmmm  still not satified with the deployment problems that linQ will generate even with what u have said ...

 

We did stoped using objectdatasource a year ago as it seems like its is saving us time but infact it really steals our time in the maintaince.....

 

linQ to SQL or LinQ will succedd if it does overcome the deployment problems we are experiencing in todays enviroment.

 

 

such as the new datacontext designer should raise errors when it does not match the database schema....other than that many things are toys but not usefull ones in real world

Answer 6

Scott's been talking about the LinqDataSource since mid-January (http://weblogs.asp.net/scottgu/archive/2007/01/21/asp-net-tips-and-tricks-and-linq-slides-demos-from-codemash.aspx). Jeff King demoed it at DevConnections (http://www.sitepoint.com/blogs/2007/03/27/devconnections-day-1-wrap-microsoft-day-at-a-microsoft-conference/) in March 2007. Anders Heljsberg demoed it at MIX07 (MIX07 Session Videos with LINQ, Entity Framework, or VB[x] Hooks).

 

In fact, Scott's been talking about DLinq designer support in ASP.NET since May 2006 when he left this comment to my DLinq, Visual Basic 9.0, and ASP.NET 2.0 Issues  post:

 

"DLINQ designer support for web projects will be coming in the future -- unfortunately it currently isn't there in the May CTP of LINQ.

One option you can use, though, is to create a class library project and use the DLINQ designer there. You should then be able to reference it from your web project.

Hope this helps,

Scott"

 

When can we expect a LinqDataSource CTP or beta drop?

 

--rj