ORMBattle.NETThe ORM tool shootout

  • Increase font size
  • Default font size
  • Decrease font size
100% Authentic zi xiu tang bee pollen weight loss Soft for you, FREE SHIPPING To Any Country., zixiutang ,Weight Loss Success. 100% Authentic super slim pomegranate weight loss success for you, Hot on sale, meizitang botanical slimming ,Best. | fruta planta Best slimming tablets cheap snapbacks weight loss Gel for you, Reduce Weight Effectively, cheap snapbacks free shipping ,. | hats wholesale
Home LINQ Implementation Tests

LINQ Implementation Tests

E-mail Print PDF
The goal of this test sequence is to show the comprehensiveness of LINQ implementation in each ORM tool.

You might know LINQ doesn't limit developers from "above" in its implementation: since LINQ allows to use any C#/VB.NET expressions in queries, particular LINQ provider can be as complex as its developer wishes. On the other hand, it would be anyway limited, because normally it is impossible to translate any C# expression to e.g SQL. If so, what do we mean when we're saying one LINQ provider is better than another? By our opinion, the quality of LINQ provider is determined by:

  1. Supported set of standard LINQ methods (extension methods exposed by Queryable type) and their complex use cases, e.g. usage of a particular LINQ method inside expression passed to another one (something similar to subquery in SQL), usage of lambda parameter defined in parent scope and so on.
  2. Supported set of operations (==, !=, and so on) and methods of standard .NET types, such as DateTime, TimeSpan, String, Double and so on
  3. Supported set of frequently used utility methods, such as methods of Math.*
  4. Supported set of operations and methods of ORM entity types. E.g. ==, != and object.Equals for entities and keys.
  5. Nullability support.
  6. Quality of translation. This implies that:
    a) translator must produce such a replacement for a particular expression that can't lead to a query plan with unexpectedly high cost. E.g. we think translation of string.StartsWith to CHARINDEX(...)==1 is bad, but translation it to ... LIKE ... is good, because second option allows query optimizer to use index seek instead of index scan, but the first one does not.
    b) ideally, produced queries must be human readable, or there must be an option to produce such queries. Although this is less important than everything else.
ORMBattle.NET LINQ test suite checks only 1...5 goals. Quality of translation (6) currently isn't tested, because it's rather difficult to do this fully automatically. Although we're planning to publish some articles related to this in future.
How the result is checked for correctness? With LINQ to enumerable. E.g. if original query was:
from c in dataContext.Customers
where c.Orders.Count==0

Its "check" query will be:

from c in dataContext.Customers.AsEnumerable()
where c.Orders.AsEnumerable().Count==0

LINQ test sequence currently consists of 117 tests, but score is measured as percentage of passed tests. Why? Mainly, because this number is quite simple to understand. But what about the above statement that it's impossible to get 100% LINQ implementation? The statement is correct, 100% score here is related just to ORMBattle.NET test sequence.

Finally, it worth to say what are common requirements to all LINQ tests:

  • Any test must pass on at least one ORM
  • Test sets are selected to test particular features. Each feature is tested using a test set composed of N tests with varying complexity. Each feature test must test (or involve) just a particular feature.
  • Multi-feature tests are organized into "Complex" test set.
  • Ideally, just few frameworks must pass the most complex test in each set.
Note: You can download the whole test suite or browse it online. We use a special tool injecting special comments (example) against each test indicating whether a test has passed or failed, so you can easily find out what does not work in each case.
Last Updated on Friday, 30 July 2010 08:08  

Polls

Which test must we add next?
 

Subscribe to our blog