DA LINQ

Background: Language Integrated Query (LINQ)

LINQ technology was introduced by Microsoft with version 3.5 of the .NET framework and is available in all mainstream .NET languages, including C#, Visual Basic .NET and our own Oxygene (a.k.a. Delphi Prism). LINQ adds new constructs to the languages that allow developers to specify queries in a syntax that vaguely resembles SQL, but is strongly typed and processed at compile time. General LINQ can work on any .NET collections of data represented by a generic IEnumerable sequence.

DA LINQ builds upon the general LINQ infrastructure provided by the framework and languages, so that developers can write LINQ queries that will be executed against middle-tier servers using DA SQL or Dynamic, making it extremely easy to create client applications that request just the data they need to work with, without having to rely on manual SQL code.

DA LINQ in Action

For example: A client application might contain the following code:

This is the equivalent of a plain SQL query like:

but with two important distinctions:

Firstly, different from the SQL query, which would be stored as string constant or constructed on the fly, the LINQ query is validated at compile time – if, for example, Name was not of type string, or the Customers table did not contain fields named CustomerID or Address, this would be indicated as a compile time error, rather than fail at runtime. This makes it much easier and more robust to write queries, as compiler and IDE intellisense can help the developer to craft correct code.

Secondly, the query will return a strongly typed collection of objects that match exactly the queried data. In the above case, the customers collection could be looped and the CustomerID, Name and Address fields of the individual elements could be accessed directly – once again the compiler will ensure correctness and type compatibility of the written code.

Minimizing Data Traffic

Different from the normal “LINQ to Objects” that works on local objects, DA LINQ does not rely on retrieving the entire data table(s) and applying the query logic locally within the client application. Instead, DA LINQ translates its queries into DA SQL or Dynamic Select requests and will fetch only the exact data requested by the query to the client. This allows developers to expose potentially huge sets of data on the server and yet write efficient client apps that only get the data they need, when they need it.

Combined with Data Abstract’s fast and low-bandwidth communication infrastructure, network traffic between client and middle-tier server can be kept to a minimum, creating applications that access data fast and efficiently, regardless of the available network quailty.

The Only Client-Side Database LINQ Technology

Of all the database frameworks that provide support for LINQ (including standard ADO.NET), DA LINQ is the only technology that employs LINQ on the client tier, allowing developers to write their LINQ queries where they matter most and in the place where the data is consumed.

This extends from standard desktop or ASP.NET applications using the main .NET Framework all the way to Silverlight applications, that can use DA LINQ to request data from their servers to drive rich, data-driven web experiences.

How Does it Work?

As hinted at above, DA LINQ is based on two other technologies in Data Abstract, using the powerful DA SQL or (optionally) DynamicSelect/DynamicWhere to transmit queries to the server.

DA SQL (covered here in more detail) supports sending of virtually arbitrary SQL requests, and thus supports the entire breadth of DA LINQ, including Select, Where, Join and Order By Clauses, among others. At runtime, the expression generated from the LINQ query statement gets translated into a DA SQL query and sent to the server for execution. The returned record set is processed automatically and packaged into a collection of strongly-typed objects that can then be looped and worked with by the client code.

DynamicSelect and DynamicWhere are two older technologies that allow clients to pass a custom Select and Where clause to the server, in order to narrow down the list of fields (Select) and the range of records (Where) returned. This option provides less flexibility than DA SQL and only supports LINQ’s Where and Select clauses, but has the benefit of working against servers that do not allow or support DA SQL – whether for technical or policy reasons.

In both scenarios, the entire data access functionality is encapsulated by the DA/.NET client library; the developer only needs to worry about crafting the query and working with the data received in return.