Il blog di Pietro Libro

EF 4.3 Released

Pietro Libro — Fri, 10 Feb 2012 06:21:00 GMT

Rilasciata la versione 4.3 di Entity Framework, tra le novità introdotte in questa release, il più interessante IMHO il supporto all’evoluzione di un database generato utilizzando l’approccio Code First. Installazione semplice ed indolore tramite NuGet : Install-Package EntityFramework. Per il supporto agli Enum bisognerà aspettare la versione 5.0 (.Net 4.5). Tutti i dettagli sul post dell’ ADO.NET Team: http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-released.aspx

DomusDotNet: WCF Data Services (Terza Parte)

Pietro Libro — Wed, 25 Jan 2012 12:59:00 GMT

Terzo ed ultimo articolo (qualcuno dirà finalmente ) della serie dedicata ai WCF Data Services. Articolo completo su DomusDotNet. Critiche, consigli e suggerimenti sono sempre ben accetti.

OData T4 for C#

Pietro Libro — Fri, 20 Jan 2012 09:54:00 GMT

Annuncio fresco fresco (quasi ) da parte del WCF Data Services Team Blog : http://blogs.msdn.com/b/astoriateam/archive/2012/01/19/announcing-odata-t4-for-c-preview-1.aspx

MCTS 70-513

Pietro Libro — Tue, 17 Jan 2012 15:15:00 GMT

Ieri, anche questo è andato. E’ stata una bella soddisfazione. Ora avanti per l’MCPD .

DomusDotNet: WCF Data Services (Seconda Parte)

Pietro Libro — Wed, 11 Jan 2012 05:56:00 GMT

Secondo articolo della serie dedicata ai WCF Data Services: utilizzo con Entity Framework, ed approfondimento su Service Operations. Nel codice allegato un client ASP.NET MVC di test. Articolo completo sul sito di DomusDotNet. Al solito, consigli e suggerimenti sono sempre ben accetti .

SharePoint 2010 e ASP.NET

Pietro Libro — Fri, 23 Dec 2011 10:18:00 GMT

Sul blog di MSDN Italia è stato aggiunto un post che riporta link ad una serie di video su SharePoint 2010 per sviluppatori ASP.NET, per chi fosse interessato, tutti i dettagli qui.Un bel regalo di Natale .

DomusDotNet: WCF Data Services (Prima parte)

Pietro Libro — Tue, 20 Dec 2011 23:00:00 GMT

Prima parte di una serie di articoli dedicati ai WCF Data Services, al protocollo OData e REST. Per gli interessati , articolo completo qui.

EF Code First Migrations Beta 1 (Parte 2)

Pietro Libro — Sun, 04 Dec 2011 06:42:00 GMT

In questa seconda parte proveremo ad eseguire gli stessi passi eseguiti in precedenza utilizzando “la migrazione automatica dello schema”. Per comodità riporto la classe DbContext ed il semplice Object Model utilizzato per la definizione dello schema del database:

 public class OfficeContext : DbContext
    {
        public OfficeContext()
            : base("OfficeDB")
        {
        }
        public DbSet<Employee> Employees { get; set; }
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);
        }
        static OfficeContext()
        {
            Database.SetInitializer<OfficeContext>(null);
        }
    }
    public class Employee
    {
        public int Id { get; set; }
        public String Name { get; set; }
        public String Surname { get; set; }
        public String Role { get; set; }
    }

Avendo aggiunto EntityFramework.Migrations in precedenza, per continuare, dobbiamo aprire la classe Configuration.cs all’interno della cartella Migrations ed impostare la proprietà AutomaticMigrationsEnabled a true:

public Configuration()
{            
    AutomaticMigrationsEnabled = true;
    AutomaticMigrationDataLossAllowed = false;
}

Inoltre impostiamo la proprietà AutomaticMigrationDataLossAllowed=false: in questo modo un’eccezione verrà sollevata nel caso in cui la migrazione dello schema comporti una perdita di dati. Nell’override del metodo Seed aggiungiamo del codice per inserire delle righe dopo la generazione\migrazione dello schema:

protected override void Seed(OfficeContext context)
{            
    context.AddOrUpdate(
        new Employee() { Name = "Mario", Surname = "Rossi", Role = "Administrator" },
        new Employee() { Name = "Giulio", Surname = "Verdi", Role = "Store Manager" },
        new Employee() { Name = "Pietro", Surname = "Libro", Role = "Art Director" }
        );
}

A differenza della procedura manuale, digitiamo direttamente il comando update-database nella console di NuGet, eventualmente utilizzato i parametri –verbose o -script rispettivamente per visualizzare o creare un file di .sql con i comandi generati da VS:

Come per la prima parte, utilizzando ad esempio SQL Management Studio, vediamo che il lavoro “sporco” sia stato eseguito correttamente come ci aspettavamo:

Ora, se volessimo apportare le stesse modifiche allo schema del modello dati, come nel caso del post precedente, dovremmo ritornare “in modalità manuale” (in quanto, in questa modalità non possiamo specificare i valori di default per i nuovi campi o utilizzare codice SQL custom) quindi utilizzando il comando Add-Migration e relativi parametri. Ovviamente abbiamo già discusso su come eseguire questi passaggi e non staremo qui a ripeterli: IMHO la migrazione automatica non mi ha entusiasmato molto a differenza di quella manuale dove è possibile intervenire in diversi punti.

Proviamo ora ad eliminare (o commentare) la proprietà Surname dall’entità Employee:

    public class Employee
    {
        public int Id { get; set; }
        public String Name { get; set; }
        public String Role { get; set; }
    }

Commentiamo il codice presente nel Seed ed eseguiamo il comando update-database:

Entity Framework ci avverte che l’aggiornamento non è stato completato perché potrebbe verificarsi una perdita di dati, ma allo stesso tempo ci suggerisce di utilizzare il parametro –force per forzare l’aggiornamento della base di dati (con conseguente data loss). Ok.

Oltre a commentare il codice (non proprio una best practice) per evitare di aggiungere dati duplicati tramite l’AddOrUpdate del Seed è sufficiente istruire VS con una Func<TEntity,Object> al fine di specificare quali proprietà devono essere considerate per identificare un record come duplicato:

System.Linq.Expressions.Expression<Func<Employee, object>> identify =
    n => new { n.Name, n.Role  };

context.AddOrUpdate(identify,
    new Employee() { Name = "Mario", Role = "Administrator" },
    new Employee() { Name = "Giulio", Role = "Store Manager" },
    new Employee() { Name = "Pietro", Role = "Art Director" }
    );

EF Code First Migrations Beta 1 (Parte 1)

Pietro Libro — Thu, 01 Dec 2011 21:59:00 GMT

Finalmente sono riuscito a trovare qualche minuto per buttare giù qualche riga a riguardo di EF Code First Migrations (da qualche giorno disponibile in beta 1). Per chi usa l’approccio Code First l’aggiornamento del modello e della base di dati sottostante (soprattutto quando contiene dati) è un grosso problema. Proviamo a testare il funzionamento del “pacchetto” su un modello molto semplice come il seguente, in un progetto console C#:

 public class OfficeContext : DbContext
    {
        public OfficeContext()
            : base("OfficeDB")
        {
        }
        public DbSet<Employee> Employees { get; set; }
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);
        }
        static OfficeContext()
        {
            Database.SetInitializer<OfficeContext>(null);
        }
    }

    public class Employee
    {
        public int Id { get; set; }
        public String Name { get; set; }
        public String Surnamte { get; set; }
        public String Role { get; set; }
    }

Aggiungiamo al progetto un file App.Config con una stringa di connessione simile alla seguente:

<add name="OfficeDB" connectionString="Data Source=(local)\SQLEXPRESS;Initial Catalog=OfficeDB;Integrated Security=True;" providerName="System.Data.SqlClient"/>

Per come abbiamo configurato il DBContext nessun database verrà generato, anzi, a runtime avremo un’eccezione di questo tipo:

Procediamo con l’installazione via NuGet del Package EntityFramework.Migrations (Code First Migrations Beta 1, ver. 0.8.0.0):

Durante il processo di installazione viene automaticamente aggiunta al progetto una nuova cartella, “Migrations” contenente il file Configuration.cs (derivata da DbMigrationsConfiguration<T> dove T è la classe OfficeContext) nel quale possiamo specificare, ad esempio, se utilizzare la “migrazione automatica del modello” (vedremo in seguito) tramite la proprietà AutomaticMigrationsEnabled (false di default), se continuare o meno una migrazione dello schema anche in presenza di perdita dei dati, AutomaticMigrationDataLossAllowed, o se sollevare un’eccezione. Inoltre tramite l’override di Seed è possibile specificare se aggiungere dopo la generazione\migrazione dello schema, dei dati al database (avendo avuto qualche problema nei test con l’estensione AddOrUpdate preferisco utilizzare codice SQL per il momento ) . La classe Configuration sarà così definita:

 internal sealed class Configuration : DbMigrationsConfiguration<OfficeContext>
    {
        protected override void Seed(OfficeContext context)
        {
            base.Seed(context);
        }
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
            AutomaticMigrationDataLossAllowed = false;
        }
    }

Ora, per eseguire la creazione del database, dobbiamo aggiungere “a scaffale” la nostra prima “migrazione”(ovvero la generazione del database): così facendo, oltre a richiamare i metodi per la generazione del database, potremmo eseguire nel tempo degli Upgrade e Downgrade utilizzando i vari piani di migrazione che andremo a creare: se uniamo a quanto detto TFS, penso non ci sia altro da aggiungere. Nella console di NuGet (Package Manager Console) digitiamo : Add-Migration [parametro] dove parametro è un etichetta che identifica in modo univoco la migrazione che stiamo aggiungendo. Nel nostro caso parametro=OfficeDBFirstMigration. Se tutto procede senza errori, la schermata della console di NuGet dovrebbe essere simile alla seguente:

Al progetto viene aggiunto un un file xxxx_OfficeDBFirstMigration.cs contenente uno “Snapshot” del modello Code First del database da creare definito dalla classe DbContext (OfficeContext per il caso specifico). Per generare il database, digitiamo il comando Update-Database (che prende in considerazione l’ultimo file di migrazione “Pending”, “a scaffale”), eventualmente aggiungendo il parametro –Verbose per visualizzare i comandi SQL generati, oppure il parametro –Script per generare un file .sql da scambiare con gli altri membri del team o eventualmente da aggiungere su TFS:

Utilizzando SQL Management Studio possiamo vedere come il database sia stato creato secondo le nostre specifiche (le colonne sono state aggiunge utilizzando le convenzioni di EF):

Prima di continuare, facciamo un passo indietro e “spulciamo” il contenuto della classe OfficeDBFirstMigration generata dal comando Add-Migration:

public partial class OfficeDBFirstMigration : DbMigration
{
    public override void Up()
    {
        CreateTable(
            "Employees",
            c => new
                {
                    Id = c.Int(nullable: false, identity: true),
                    Name = c.String(),
                    Surname = c.String(),
                    Role = c.String(),
                })
            .PrimaryKey(t => t.Id);
        CreateTable(
            "EdmMetadata",
            c => new
                {
                    Id = c.Int(nullable: false, identity: true),
                    ModelHash = c.String(),
                })
            .PrimaryKey(t => t.Id);
        Sql("INSERT INTO Employees ([Name],[Surname],[Role]) VALUES ('Pietro','Libro','Art Director')");
        Sql("INSERT INTO Employees ([Name],[Surname],[Role]) VALUES ('Mario','Rossi','Administrator')");
        Sql("INSERT INTO Employees ([Name],[Surname],[Role]) VALUES ('Giulio','Verdi','Store Manager')");
    }
    public override void Down()
    {
        DropTable("EdmMetadata");
        DropTable("Employees");
    }
}

Nella classe è stato generato l’override dei metodi Up e Down (sembra il motivo di una canzone di qualche anno fa ) . Up, come è facile intuire, contiene il codice eseguito per l’esecuzione dell’upgrade dello schema della base dati, Down, il codice eseguito per effettuare il downgrade ad una versione precedente della base dati. La lettura del codice è abbastanza semplice, ed in questo punto possiamo intervenire per specificare manualmente (ove necessario) quanto non automaticamente generato da VS: ad esempio avremmo potuto aggiungere del codice per specificare degli indici (automatico per le chiavi primarie, Id nello specifico) o delle Foreign Key. Inoltre possiamo aggiungere del codice SQL personalizzato utilizzando il metodo SQL (…). Utilizziamo questo metodo per aggiungere tre righe alla tabella Employees.

Eseguendo il nostro progetto , il risultato che otteniamo è mostrato figura:

Modifichiamo il modello dati, nello specifico l’entità Employee: aggiungiamo la colonna CardID (di tipo stringa) contenente il numero identificativo stampato sul badge di ogni dipendente, ed impostiamo tramite override dell’OnModelBuilder la lunghezza massima del campo a 20 caratteri. Inizialmente tutti i dipendenti dovranno avere un identificativo del tipo “00000-00000”. Procediamo con il comando Add-Migration OfficeDBSecondMigration, per aggiungere un nuovo piano di migrazione, ovvero un nuovo file .cs del tipo xxxxxx_OfficeDBSecondMigration.cs, che andiamo immediatamente ad ispezionare per aggiungere del codice personalizzato (per impostare il default value) prima di procedere con l’aggiornamento:

public partial class OfficeDBsecondMigration : DbMigration
{
    public override void Up()
    {
        AddColumn("Employees", "CardID", c => c.String(nullable: false, defaultValue: "00000-00000", maxLength:20));
    }
    public override void Down()
    {
        DropColumn("Employees", "CardID");
    }
}

(Nota: invertendo l’ordine tra defaultValue e maxLength sull’ambiente di test viene sollevata un’eccezione , d’altra parte non sarebbe una beta ). Procediamo con l’aggiornamento (Update-Database). Vediamo cosa è successo:

Quello che ci aspettavamo. Utilizzando solo Code First, questo processo di aggiornamento sarebbe risultato distruttivo e comunque avrebbe richiesto un certo effort di modifiche “a manina”. Prima di concludere cerchiamo di aumentare la complessità del modello aggiungendo una tabella Roles ed una relazione uno-a-molti tra le entità Employee e Role:

Mettiamo in pending il nuovo schema dati (Add-Migration OfficeDBThirdMigration):

public partial class OfficeDBThirdMigration : DbMigration
{
    public override void Up()
    {
        CreateTable(
            "Roles",
            c => new
                {
                    Id = c.Int(nullable: false, identity: true),
                    Description = c.String(),
                })
            .PrimaryKey(t => t.Id);
        AddColumn("Employees", "Role_Id", c => c.Int());
        AddForeignKey("Employees", "Role_Id", "Roles", "Id");
        CreateIndex("Employees", "Role_Id");
        DropColumn("Employees", "Role");
        Sql("INSERT INTO Roles (Description) VALUES ('Administrator')");
        Sql("INSERT INTO Roles (Description) VALUES ('Store Manager')");
        Sql("INSERT INTO Roles (Description) VALUES ('Art Director')");
        Sql("UPDATE Employees SET Role_ID = 1 WHERE Name='Mario' AND Surname ='Rossi'");
        Sql("UPDATE Employees SET Role_ID = 2 WHERE Name='Giulio' AND Surname ='Verdi'");
        Sql("UPDATE Employees SET Role_ID = 3 WHERE Name='Pietro' AND Surname ='Libro'");
    }
    public override void Down()
    {
        AddColumn("Employees", "Role", c => c.String());
        DropIndex("Employees", new[] { "Role_Id" });
        DropForeignKey("Employees", "Role_Id", "Roles", "Id");
        DropColumn("Employees", "Role_Id");
        DropTable("Roles");
    }
}

A cui abbiamo aggiunto del codice SQL custom. Un ultimo Update-Database ed il gioco è fatto:

Il risultato ovviamente non cambia

Per eseguire l’upgrade-downgrade del modello dati è sufficiente invocare il metodo Update-Database –targetmigration [parametro] dove [parametro] è uno dei nomi utilizzati in precedenza (ad esempio OfficeDBFirstMigration ). Vedremo nel prossimo post il funzionamento della modalità “automatica” di migrazione.

Code First Migrations: Beta 1 Released

Pietro Libro — Wed, 30 Nov 2011 10:52:00 GMT

Rilasciata la versione Beta 1 di Code First Migrations. Tutti i dettagli qui. La semplicità di utilizzo è veramente notevole .

Expression, LambdaExpression, Entity Framework (e DDD)

Pietro Libro — Thu, 10 Nov 2011 06:11:00 GMT

Se lavoriamo con EF utilizzando l’approccio Code First, in alcuni scenari, il mapping (ad esempio nel caso di classi di dominio già esistenti) potrebbe essere un task non banale. Riprendiamo un esempio di qualche tempo fa , aggiungendo all’Object Model l’entità Articolo, come riassunto dal Class Diagram seguente:

Fattura espone una collezione di oggetti RigoFattura accessibile (dall’esterno) tramite l’IEnumerable<RigoFattura> pertanto, l’unico modo di aggiungere nuove righe alla fattura è l’utilizzo del metodo AddRigoFattura. Ancora, la classe RigoFattura contiene una proprietà CodiceArticolo che ritorna la proprietà Codice dell’istanza della classe Articolo referenziata, ma anche in questo caso, l’unico modo per aggiungere un Articolo è tramite un metodo : ImpostaArticolo. A questo punto qualcuno potrebbe dire, “Si ok, ma dov’è il problema ?” Come descritto nel post precedente, durante il mapping, nell’override dell’OnModelBuilder, abbiamo qualche problema in fase di compilazione:

Questo perché le Fluent API, come è facile intuire, non vanno d’accordo con i membri Protected (o comunque non accessibili dall’esterno). In questi casi, la soluzione che possiamo adottare è quella di creare una serie di Extension Methods che basandosi sul nome delle Proprietà e Navigation Properties ci permettano di creare delle espressioni da poter utilizzare nel nostro scenario di mapping:

public static class Methods
{
    private static Expression<Func<T, K>> CreateExpression<T, K>(String propertyName)
    {
        Type type = typeof(T);
        PropertyInfo pi = type.GetProperty(propertyName, BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
        if (pi == null) throw new ArgumentException("propertyName is not valid.");
        ParameterExpression argumentExpression = Expression.Parameter(type, "x");
        MemberExpression memberExpression = Expression.Property(argumentExpression, pi);
        LambdaExpression lambda = Expression.Lambda(memberExpression, argumentExpression);
        Expression<Func<T, K>> expression = (Expression<Func<T, K>>)lambda;

        return expression;
    }
    public static PrimitivePropertyConfiguration Property<TEntity, KPropertyType>(this EntityTypeConfiguration<TEntity> mapper, String propertyName)
        where TEntity : class
        where KPropertyType : struct
    {
        Expression<Func<TEntity, KPropertyType>> expression = CreateExpression<TEntity, KPropertyType>(propertyName);
        return mapper.Property(expression);
    }

    public static DependentNavigationPropertyConfiguration<TEntity> WithMany<TEntity, KTargetEntity>(
        this  OptionalNavigationPropertyConfiguration<TEntity, KTargetEntity> mapper, String propertyName)
        where TEntity : class
        where KTargetEntity : class
    {
        Type type = typeof(KTargetEntity);
        ParameterExpression argumentExpression = Expression.Parameter(type, "x");
        PropertyInfo pi = type.GetProperty(propertyName, BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
        MemberExpression memberExpression = Expression.Property(argumentExpression, pi);
        LambdaExpression lambda = Expression.Lambda(memberExpression, argumentExpression);
        var expression = (Expression<Func<KTargetEntity, ICollection<TEntity>>>)lambda;

        return mapper.WithMany(expression);
    }

    public static RequiredNavigationPropertyConfiguration<TEntity, TTargetEntity> HasRequired<TEntity, TTargetEntity>(this EntityTypeConfiguration<TEntity> mapper, String propertyName)
        where TEntity : class
        where TTargetEntity : class
    {
        Expression<Func<TEntity, TTargetEntity>> expression = CreateExpression<TEntity, TTargetEntity>(propertyName);
        return mapper.HasRequired(expression);
    }

    public static EntityTypeConfiguration<TEntity> HasKey<TEntity, KKeyType>(this EntityTypeConfiguration<TEntity> mapper, String propertyName)
        where TEntity : class
        where KKeyType : struct
    {
        Expression<Func<TEntity, KKeyType>> expression = CreateExpression<TEntity, KKeyType>(propertyName);
        EntityTypeConfiguration<TEntity> m = mapper.HasKey<KKeyType>(expression);
        return mapper;
    }

    public static ManyNavigationPropertyConfiguration<T, U> HasMany<T, U>(this EntityTypeConfiguration<T> mapper, String propertyName)
        where T : class
        where U : class
    {
        Type type = typeof(T);
        PropertyInfo pi = type.GetProperty(propertyName, BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
        if (pi == null) throw new ArgumentException("propertyName is not valid.");
        ParameterExpression parameterExpression = Expression.Parameter(type, "x");
        MemberExpression memberExpression = Expression.Property(parameterExpression, pi);
        LambdaExpression lambda = Expression.Lambda(memberExpression, parameterExpression);
        Expression<Func<T, ICollection<U>>> expression = (Expression<Func<T, ICollection<U>>>)lambda;
        
        return mapper.HasMany(expression);
    }

A questo punto il gioco è facile, definendo il modello in questo modo:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    modelBuilder.Entity<RigoFattura>();
    modelBuilder.Entity<RigoFattura>().ToTable("RigoFattura");
    modelBuilder.Entity<RigoFattura>().Ignore(rf => rf.CodiceArticolo);

    modelBuilder.Entity<RigoFattura>().HasRequired<RigoFattura, Articolo>("Articolo");            

    modelBuilder.Entity<Fattura>().ToTable("Fattura");
    modelBuilder.Entity<Fattura>().HasKey<int>(f => f.Numero);
    modelBuilder.Entity<Fattura>().HasMany<Fattura, RigoFattura>("RigheFatture");

    modelBuilder.Entity<Articolo>().ToTable("Articoli");
    modelBuilder.Entity<Articolo>().HasKey(a => a.Codice);            
}

Tutto funziona correttamente, e l’esecuzione del codice porta alla corretta creazione del Database come riassunto dal Database Diagram seguente:

Gli Extension Methods descritti in precedenza, non servono solo a coprire lo scenario descritto nel post, ma anche nel caso di : WithMany, HasKey, HasMany, Property ecc… Aggiungere altri metodi personalizzati è relativamente semplice. Cosa facciamo nel codice: 1) tramite reflection recuperiamo le proprietà che entrano in gioco durante lo scenario di mapping e che non sono visibili dall’esterno 2) Creiamo una ParameterExpression con il tipo entità (TEntity) 3) Creiamo una MemberExpression a partire dalla proprietà ottenuta via reflection e dalla ParameterExpression ottenuta al punto precedente 3) Mettiamo tutto insieme, creiamo una Lambda Expression e da questa una Expression<Func<,>> accettata dal mapper. In tre “semplici” passi aggiungiamo uno “strato” che ci permette di coprire scenari di mapping “ostici”.

Nota bene: questo post non vuole essere in contraddizione con quanto precedentemente scritto a proposito di DDD ed EF, ma presenta solo un workaround per bypassare il problema, ma con tutte le problematiche del caso: di solito le parole “Stringhe” e “Refactoring” non vanno molto d’accordo (se ad esempio cambiamo il nome di una proprietà di una classe, la stringa associata non viene cambiata, creando una “fantastica” eccezione a runtime). Si spera che le prossime release di Entity Framework permettano di risolvere anche questo scoglio.

EF 4.2 Released

Pietro Libro — Wed, 02 Nov 2011 07:21:51 GMT

E' stata rilasciata la versione finale di EF 4.2 contenente aggiornamenti riguardanti il DbContext ed il Code First runtime. L'utilizzo degli Enum, Spatial Data-Type ecc...(vedi EF June CTP 2011) non è incluso in questo aggiornamento, in quanto richiederebbe delle modifiche alle librerie del .Net Framework. Il download di EF 4.2 è disponibile via NuGet.
Al solito, per maggiori dettagli: ADO.NET team blog.

EF 4.2 Release Candidate

Pietro Libro — Tue, 11 Oct 2011 06:07:00 GMT

E’ stata rilasciata la versione 4.2 Release Candidate di Entity Framework. Tutti i dettagli relativi qui

DomusDotNet : Pomeriggio Entity Framework

Pietro Libro — Tue, 11 Oct 2011 05:28:00 GMT

Venerdì 7 ottobre si è tenuto l’evento Pomeriggio Entity Framework organizzato da DomusDotNet. L’argomento sembra aver suscitato un certo interesse dato il numero di presenze. Si è discusso dei vari approcci di utilizzo dell’O\RM di Casa Microsoft : Database First & Model First, Alessandro Mostarda, Code First (io, nonostante non fosse la mia prima esperienza da Speaker era la prima volta in casa Microsoft ) , WP7 e Database Locali (Nicolò). Grazie a tutti partecipanti !!! A presto! Qualche foto dell’evento:

Da sinistra verso destra: Vela DomusDotNet, Nick 1 e 2, Alessandro, Io 3 e 4. Alla prossima !

Code First Migrations: Alpha 2 Released

Pietro Libro — Thu, 08 Sep 2011 09:05:00 GMT

Maggiori info ed un dettagliato Walkthrough qui.