Entity Framework 2.0

I nästa version av Entity Framework har mycket intryck och åsikter från Community och speciellt ett externt “design-team” fått vara ledande för hur ramverket ska se ut och hanteras. Kritiken som har låtit sig höras om version 1.0 har handlat om objektmodellens olika brister på grund av att entitets klasser antingen behövt ärva från basklasser eller implementerat en del interface. Kritik på verktygen och avsaknanden av möjligheten att generera databasen baserat på den konceptuella objektmodellen har också kommit till vår kännedom.

Därför är det extra kul att få se de tidiga “bitarna” på PDC’n på hur vi har förändrat oss och verkligen tagit till oss av kritiken. Ett exempel på en renare objektmodell är följande exempelkod som helt enkelt beskriver en delmängd av en produkt i Northwind-databasen:

public class Product

{

    public int ProductID { get; set; }

    public string Name { get; set; }

}

Observera den totala avsaknaden av basklasser, implementationer av gränssnitt osv…

Men då kanske du tänker, hur vet Entity Framework vilken tabell som representerar modellens entititer, vilka kolumner som innehåller respektive egenskaps värde osv. Här har också utvecklarna lyssnat på förslagen och rekommendationerna från communityn som sa följande:

Primärt så vill vi att Entity Framework själv ska försöka lista ut “mappningen” eller kopplingen, sekundärt så kan attribut användas för att explicit styra kopplingarna. Sista alternativet är XML-mappningsfiler som hanterar kopplingen.

Därför har EntityFramework fått lite ny funktionalitet som enklast kan beskrivas som att använda en generisk Factory som hanterar mappningen baserat på ett specifikt ObjectContext objekt. Så här kan ett enkelt ObjectContext se ut.

public class DemoContext : ObjectContext

{

    public DemoContext(EntityConnection connection) : base(connection) { }

 

    private ObjectSet<Product> _products;

 

    public ObjectSet<Product> Products

    {

        get

        {

            if (_products == null)

                _products = CreateObjectSet<Product>("DemoContext.Products");

            return _products;

        }

    }

}

Vad jag gör i exemplet ovan är att ärva från basklassen ObjectContext och sedan skapa en publik egenskap av den generiska typen ObjectSet med min Product klass som typ-parameter. I “gettern” skapar jag (i det fall det inte redan existerar) ett ObjectSet med hjälp av en generisk metod som finns i ObjectContext-basklassen. Sträng-parametern kan jag idag inte riktigt förklara men det kommer nog att klarna framöver, det är i alla fall <Klass>.<Egenskap>.

För att sedan kunna använda context-klassen i min applikation så använder jag den tidigare nämnda Factory-klassen på följande sätt:

using (DemoContext context =

       ContextFactory.CreateContext<DemoContext>(CONNECTION_STRING))

{

    var query = from p in context.Products

                select p;

 

    foreach (Product p in query)

    {

        Console.WriteLine(p.Name);

    }

}

Visst ser det ganska enkelt ut? Vill du se det verkligen fungera så har jag publicerat en film på MSDN TV via Channel9.

Comments

• Anonymous
  November 13, 2008
  PingBack from http://www.tmao.info/entity-framework-20/

• Anonymous
  November 15, 2008
  Det finns en hel del saker jag har suttit och svorit över angående EF när jag har använt det på befintliga databaser. Iofs så har jag svorit ännu mer över databasstrukturen på dessa, då den ofta inte är särskilt genomtänkt, men det borde inte spela någon roll. Jag hoppas verkligen att EF fungerar bättre i nästa version och det skall bli väldigt intressant att se vart det leder. I värsta fall så får man väl helt enkelt skriva ett eget lager ovanpå det som rättar till problemen som dyker upp.

• Anonymous
  November 26, 2008
  Vilka problem? Tycker EF funkar KANON, går tokfort att köra igång ett nytt projekt: skapa datamodellen i SQL2008, läs upp som EF i VS2008, done!

• Anonymous
  December 01, 2008
  Fint, låter ju rätt likt NHibernate.