EntityFramework

It is an analysis on how we can implement Entity Framework.

scale

The total amount of members in corcompare is about 800, which is about 3 to 4 times bigger than Linq to SQL (which was AFAIR about 250 missing stuff).

Components, in to-be-implemented order

The order is actually a rough guess.

  1. System.Data.Metadata.Edm (entity data model)
  2. Entity SQL (esql) parser
  3. System.Data.EntityClient (ADO.NET provider to EDM)
  4. System.Data.Objects.DataClasses (EntityObject basis)
  5. System.Data.Common.CommandTrees (Expression Tree for EF)
  6. System.Data.Common (Provider basis for Edm)
  7. System.Data.Objects (ObjectQuery)

1) and 3) could be implemented within ADO.NET 2.0 core knowledge and experience on ADO.NET core would be precious here.

For 2), anyone with parser knowledge (like Mono.Data.SqlExpressions or XPath) would fit there.

4) would not be a big task. But I have to say, I'm unsure about this layer.

For 5) we might make use of DBLinq "sugar" module to understand things in depth and optionally reuse the code. I'm not sure how they are similar or different yet.

For 6) we need xml parsing to populate couple of mapping/settings.

7) is to unite and implement them. For 5) we could use some db providers (npgsql/sqlite/firebird etc.) which contain support for EF.

Probably it is one hacker / year to get full component implemented as alpha shape (but monkeys may do it quicker). And probably more couple of months to get it stabilized.

dogfoods

  1. EntityDataSource, in ASP.NET works like LinqDataSource in 3.5.
    1. It could be used with DynamicData, which is not much complicated.
    2. Data Services is another option, but it requires much more code.
  2. As mentioned above, Npgsql/SQLite/Firebird seem to support EF.