It must:
- Either use POCO entities, or be able to materialize (create) initialized entities quite fast. Fast in .NET, in particular, means it use as less RAM as it's possible (that's why POCO is a good approach here). This is required to win materialization test.
- Be as simple as it's possible. Again, that's about performance on materialization test. But complex enough to support reference fields and simplest collections (sets). Otherwise it won't be highly scored on LINQ tests.
- Communicate with database quite efficiently. No any chattiness. Otherwise there are no any chances to win CUD tests, and later - TPC tests.
- Provide very good LINQ support. The queries we run test not just regular, but extreme cases, such as First/Single and Take/Skip in subqueries with groupings, and so on.
- Be highly optimized. If it was never profiles, it has nearly zero chances to be even #2...#3 here. The leader on each test shows it is highly optimized at least for this particular test case.
Post scriptum
This question has appeared during first days of this web site's life - originally many people were claiming we intentionally chosen such tests in this benchmark that intrinsically show DataObjects.Net (our own product) is the best one. So I explained that, on contrary, DataObjects.Net has almost zero chances being the fastest product here, and the reasoning of this is really simple: it isn't a lightweight ORM layer.
As we know now, there is a real-life proof of this statement: BLToolkit. It fits the description provided above very well (with some exceptions, of course - e.g. its LINQ score isn't very good yet).
