Posts
256
Comments
330
Trackbacks
7
gennaio 2010 Entries
IT Architect, questo sconosciuto…

 

Volevo sottoporre alla vostra attenzione un “piccolo” quesito, forse banale a molti: spesso mi trovo a  parlare con persone che si presentano come “IT Architect”, “Software Architect” o cose del genere, ma dopo qualche minuto di conversazione, altro che “Architect”, neanche “Murator” (senza offesa per nessuno). Quindi mi chiedevo, quali sono i “requisiti” per definirsi “Architect” ? Sono necessarie delle certificazioni (se non ricordo male si…) ? Cosa ne pensate ? Grazie a chiunque voglia rispondere.

posted @ lunedì 11 gennaio 2010 12.29 | Feedback (18)
[OT] BASTA!Italia 2010: due free pass

 

DotNetRomaCesta e BASTA!Italia, mettono in palio due free pass per l’edizione 2010 dell’evento: dettagli per partecipare all’estrazione a questo indirizzo.

posted @ lunedì 11 gennaio 2010 10.53 | Feedback (1)
Entity Framework 4: POCO e Complex Type

 

Proviamo a modificare il Data Model precedente , per testare il supporto di  Visual Studio 2010 ai Complex Type. Eliminiamo dall’entità Persona la proprietà Indirizzo, sostituendola con le proprietà Via, NumeroCivico, Comune e Provincia di tipo stringa:

image

Le proprietà elencate sono le candidate per il tipo complesso Indirizzo. A differenza della versione precedente di Entity Framework, in cui bisogna modificare a mano il codice del file .edmx, Visual Studio 2010 ci viene incontro: selezioniamo con il mouse le proprietà precedentemente citate tenendo premuto il tasto CTRL, premiamo il tasto destro del mouse e scegliamo “Refactor into New Complex Type”, come in figura:

image

Nel Model Browser rinominiamo il Complex Type “ComplexType1” appena creato in “Indirizzo” :

image

A questo punto, l’EDM Designer, dovrebbe assomigliare a qualcosa di questo tipo:

image

Visualizzando il Mapping Details, possiamo osservare come Visual Studio mappa le nostre entità alle tabelle del database:

image 

Per avere un’applicazione completa, non ci resta che modificare le classi POCO: selezioniamo il progetto “EF4FeaturesPOCO” ed aggiungiamo una nuova classe Indirizzo:


public class Indirizzo
{
    public string Via { get; set; }
    public string Comune { get; set; }
    public string NumeroCivico {get;set;}
    public string Provincia { get; set; }
}

e modifichiamo il codice della classe Persona:


public class Persona 
{ 
    public int Id { get; set; } 
    public string Nome { get; set; } 
    public string Cognome { get; set; } 
    public Indirizzo Indirizzo { get; set; } 
    public List<Ente> Enti { get; set; } 
}

Non ci resta che modificare il codice per l’inserimento di una nuova persona:


EF4FeaturesData.PersonaManager manager = new EF4FeaturesData.PersonaManager(); 
Persona p = new Persona(); 
p.Enti = new List<Ente>(); 
p.Cognome = "PIETRO"; 
p.Nome = "LIBRO"; 
 
p.Indirizzo = new Indirizzo() 
{ 
    Comune = "ROMA", 
    NumeroCivico = "s.n.c.", 
    Provincia = "RM", 
    Via = "Via Una Via Di Roma" 
}; 
 
Ente e = new Ente(); 
e.Persone = new List<Persona>(); 
e.Denominazione = "NUOVA SOCIETA' s.r.l."; 
e.Sigla = "NS"; 
 
manager.Aggiungi(p, e);           
 
Console.WriteLine("Nel DB sono presenti le seguenti persone:"); 
 
foreach (Persona per in manager.OttieniElencoPersone()) 
{                
    Console.WriteLine("{0} {1} ID={2}", per.Nome, per.Cognome, per.Id); 
    Console.WriteLine("Via: {0}", per.Indirizzo.Via); 
    Console.WriteLine("Comune: {0}", per.Indirizzo.Comune); 
    Console.WriteLine("Provincia: {0}", per.Indirizzo.Provincia); 
    Console.WriteLine("Appartiene ai seguenti enti:"); 
    foreach (Ente ent in per.Enti) 
    { 
        Console.WriteLine("===>{0}", ent.Denominazione); 
    } 
}

Eseguendo l’applicazione, otteniamo:

image

Piccola osservazione: un secondo modo possibile (oltre al codice a manina) per aggiungere un Complex Type al nostro modello, è quello di selezionare “Add\Complex Type” dal menu contestuale visualizzabile tramite click del testo destro del mouse dell’EDM designer:

image

posted @ domenica 10 gennaio 2010 18.57 | Feedback (3)
Entity Framework 4: Persistence-Ignorant Objects (POCO Support)

 

Nel post precedente abbiamo visto una delle novità più evidenti della nuova versione di Entity Framework, il supporto allo sviluppo Model First. Un'altra feature riguarda il supporto verso i tipi POCO (plain-old CLR objects): in pratica, abbiamo la possibilità di utilizzare le nostre classi custom, costituenti il Domain Model dell’applicazione, con il Data Model, senza dover far nulla (o quasi), è infatti sufficiente mappare le nostre classi con l’entità del modello dei dati per avere a disposizione gli stessi (o quasi) comportamenti (query, inserimento ed aggiornamento dei dati etc…) che si hanno con le classi entità con cui siamo abituati a lavorare ora. Alcuni dei vantaggi che mi vengono in mente, sfruttando questa nuova funzione, sono: possibilità di migrare vecchie procedure affinché possano utilizzare i vantaggi offerti da EF, sviluppo “Code-First”, sviluppo TDD (Test-Driven Development), Testing.

In questo esempio, andremo ad utilizzare il database creato nel post precedente, ma con una nuova soluzione di Visual Studio 2010 beta 2, denominata EF4Features, a cui andremo ad aggiungere due C# Library Project:

  1. EF4FeaturesData, contente il modello dei dati.
  2. EF4FeaturesPOCO, contenente i le nostre classi POCO.

Prima di proseguire, nel progetto EF4FeaturesData, andiamo ad aggiungere un riferimento al progetto EF4FeaturesPOCO. A questo punto la nostra soluzione dovrebbe essere simile a qualcosa di questo tipo:

image

Nel progetto EF4FeaturesData aggiungiamo un nuovo item ADO.NET Entity Data Model, che possiamo chiamare EF4FeaturesDataModel.edmx. Però, a differenza del post precedente, invece di partire da un modello dati vuoto, nel Wizard, scegliamo Generate from database:

image

Dopo aver premuto Next, verrà visualizzata una seconda schermata dove potremo selezionare la connessione al database (che dovrebbe essere già presente nell’elenco delle connessioni disponibili). Premendo nuovamente su next, il Wizard ci chiede di scegliere quali oggetti del nostro database vogliamo aggiungere al nostro modello: scegliamo tutte le tabelle tranne sysdiagrams ed impostiamo il namespace del nostro modello come EF4FeaturesData:

image

A questo punto premiamo su Finish e dopo qualche secondo, nell’elenco dei file del nostro progetto vedremo comparire il file EF4FeaturesDataModel.edmx. Prima di continuare, visualizziamo la finestra delle proprietà del file EF4FeaturesDataModel.edmx e cancelliamo il contenuto della proprietà Custom Tool (perché saremo noi a scrivere il codice che generalmente è automaticamente generato da Visual Studio).

image

Selezioniamo il progetto EF4FeaturesPOCO e aggiungiamo due nuove classi (le nostre POCO), Ente e Persona, il cui codice è rispettivamente:

public class Ente
{
    public int Id { get; set; }
    public string Denominazione { get; set; }
    public string Sigla { get; set; }
    public List<Persona> Persone { get; set; }
}

e
public class Persona 
{ 
    public int Id { get; set; } 
    public string Nome { get; set; } 
    public string Cognome { get; set; } 
    public string Indirizzo { get; set; } 
    public List<Ente> Enti {get;set;} 
}
 

Da notare come le Navigation Properties (Ente.Persone e Persone.Enti) presenti nel nostro modello dei dati, siano state tradotte in List<T>. Per poter eseguire query e la persistenza dei dati, abbiamo necessità di creare la nostra classe EF4FeaturesContext derivata da ObjectContext. Veramente banale:


public class EF4FeaturesContext : ObjectContext 
   { 
       private ObjectSet<EF4FeaturesPOCO.Persona>_persone = null; 
       private ObjectSet<EF4FeaturesPOCO.Ente> _enti = null; 
 
       public EF4FeaturesContext() 
           : base("name=EF4DataModel", "EF4DataModel") 
       { 
           _persone = CreateObjectSet<EF4FeaturesPOCO.Persona>(); 
           _enti = CreateObjectSet<EF4FeaturesPOCO.Ente>(); 
       } 
 
       public ObjectSet<EF4FeaturesPOCO.Persona> Persone 
       { 
           get { return _persone; } 
       } 
 
       public ObjectSet<EF4FeaturesPOCO.Ente> Enti 
       { 
           get { return _enti; } 
       } 
   }
 

Nel codice, CreateObjectSet crea una nuova istanza della classe ObjectSet<>, utilizzata per eseguire query, aggiungere, modificare ed eliminare oggetti dello specifico tipo. ObjectSet<> a sua volta estende le funzionalità della classe ObjectQuery<> presente nella versione precedente di Entity Framework. Ulteriori dettagli su queste due classi possono essere recuperati dalla versione beta di MSDN: http://msdn.microsoft.com/en-us/library/dd412652(VS.100).aspx (ObjectContext.CreateObjectSet(TEntity)) e http://msdn.microsoft.com/en-us/library/dd412719(VS.100).aspx (ObjectSet(TEntity)).

A questo punto, possiamo creare una classe “manager” che si occupi di eseguire l’inserimento di una nuova persona ed ottenere l’elenco delle persone già registrate utilizzando EF4FeaturesContext:


public class PersonaManager 
{ 
    public int Aggiungi(EF4FeaturesPOCO.Persona p) 
    { 
        using (EF4FeaturesData.EF4FeaturesContext context = new EF4FeaturesData.EF4FeaturesContext()) 
        { 
            context.AddObject("Persone", p); 
            int result = context.SaveChanges(); 
        } 
        return p.Id; 
    } 
    public List<EF4FeaturesPOCO.Persona> OttieniElencoPersone() 
    { 
        using (EF4FeaturesData.EF4FeaturesContext context = new EF4FeaturesData.EF4FeaturesContext()) 
        { 
            var q = from c in context.Persone orderby c.Cognome select c; 
            return q.ToList(); 
        } 
    } 
}

Testiamo il tutto aggiungendo alla nostra soluzione un nuovo progetto C# Console Application, scrivendo nel Main qualcosa di questo tipo (dopo aver impostato i riferimenti ai progetti già presenti nella soluzione):

EF4FeaturesData.PersonaManager manager = new EF4FeaturesData.PersonaManager(); 
Persona p = new Persona(); 
p.Cognome = "LIBRO"; 
p.Nome = "PIETRO"; 
p.Indirizzo = "Via di qualcosa"; 
 
Console.WriteLine("La persona {0} {1} e' stata aggiunta con ID {2}", 
    p.Nome,p.Cognome, manager.Aggiungi(p)); 
 
Console.WriteLine("Nel DB sono presenti le seguenti persone:"); 
 
foreach (Persona per in manager.OttieniElencoPersone()) 
{ 
    Console.WriteLine("{0} {1} ID={2}", per.Nome, per.Cognome, per.Id); 
} 
 

Eseguendo l’applicazione, otteniamo:

image

Proviamo ora a gestire la relazione: aggiungiamo un overload del metodo PersonaManager.Aggiungi(…) che accetti  un’istanza della classe persona ed una di Ente, in questo modo:

public int Aggiungi(EF4FeaturesPOCO.Persona p,EF4FeaturesPOCO.Ente e) 
      { 
          using (EF4FeaturesData.EF4FeaturesContext context = new EF4FeaturesData.EF4FeaturesContext()) 
          { 
              context.AddObject("Persone", p); 
              context.AddObject("Enti", e); 
 
              p.Enti.Add(e); 
              e.Persone.Add(p); 
 
              int result = context.SaveChanges(); 
          } 
          return p.Id; 
      }
 

Modifichiamo PersonaManager.OttieniElencoPersone() così (in modo da caricare automaticamente anche gli enti di ogni persona):

public List<EF4FeaturesPOCO.Persona> OttieniElencoPersone() 
       { 
           using (EF4FeaturesData.EF4FeaturesContext context = new EF4FeaturesData.EF4FeaturesContext()) 
           { 
               var q = from c in context.Persone.Include ("Enti") orderby c.Cognome select c; 
               return q.ToList(); 
           } 
       }
 

Ora il Main:

EF4FeaturesData.PersonaManager manager = new EF4FeaturesData.PersonaManager(); 
Persona p = new Persona(); 
p.Enti = new List<Ente>(); 
p.Cognome = "PINCO"; 
p.Nome = "PALLO"; 
p.Indirizzo = "Via di qualcosa"; 
 
Ente e = new Ente(); 
e.Persone = new List<Persona>(); 
e.Denominazione = "NUOVA SOCIETA' s.r.l."; 
e.Sigla = "NS"; 
 
manager.Aggiungi(p, e); 
 
Console.WriteLine("Nel DB sono presenti le seguenti persone:"); 
 
foreach (Persona per in manager.OttieniElencoPersone()) 
{                
    Console.WriteLine("{0} {1} ID={2}", per.Nome, per.Cognome, per.Id); 
    Console.WriteLine("Appartiene ai seguenti enti:"); 
    foreach (Ente ent in per.Enti) 
    { 
        Console.WriteLine("===>{0}", ent.Denominazione); 
    } 
}
 

Eseguendo nuovamente l’applicazione otterremo qualcosa di questo tipo:

image 

La magia si compie grazie ai metadati memorizzati nel file .edmx, che permettono al .NET Framework di eseguire l’accesso al database e persistere i dati. Lo sforzo che il team di ADO.NET sta portando avanti  è veramente notevole. Qualche osservazione: primo, per grandi progetti sarebbe molto oneroso scrivere “a manina” le varie classi POCO, Entity Framework 4.0 ci viene incontro mediante l’utilizzo di un tool molto potente basato su T4, attraverso script personalizzabili, secondo, in questo post non sono stati affrontati i problemi relativi a Lazy Loading, Change Tracking e Proxies.

Technorati Tag: ,
posted @ martedì 5 gennaio 2010 18.28 | Feedback (3)
Entity Framework in .NET 4.0 – Model First

 

E’ da qualche tempo che avrei voluto scrivere qualche post a riguardo della nuova versione dell’Entity Framework, ma per vari motivi ho sempre dovuto rimandare. Finalmente, il momento è arrivato. Durante, il corso dell’anno precedente mi sono trovato ad utilizzare Entity Framework in molti progetti, di piccola e media complessità e devo essere sincero: nonostante i problemi di gioventù (testing ad esempio…), alla fine, ho avuto modo di apprezzare, soprattutto in fase di manutenzione del software, il tempo risparmiato, se dovessi paragonare la stessa tipologia di lavoro utilizzando DataSet tipizzati invece di “Entità”. E’ vero anche, che al fine di disaccoppiare il più possibile i layer logici, è stato necessario dover scrivere (in alcuni casi, non poco) codice per gestire correttamente la situazione, e non dover portarsi dietro sia a livello di progetto che a runtime, tutti i vari riferimenti necessari ai vari EntityObject per funzionare (la situazione potrebbe complicarsi se il DAL si trovasse su un tier completamente diverso da quello della BLL). Vediamo una delle nuove funzionalità introdotte con la nuova versione di Entity Framework: la possibilità di utilizzare un approccio Model First: la generazione concettuale del modello prima del modello di storage (il database in questo caso).

Supponiamo, di voler creare una semplice applicazione per la gestione di un’anagrafica composta da persone ed enti. Le specifiche della nostra applicazione indicano che una persona può essere collegata a più società e che una società può avere più persone, una tipica relazione molti-a-molti. In un approccio data-driven, a questo punto, la prima cosa che faremmo sarebbe aprire (ad esempio) SQL Server Management Studio  e progettare le  tabelle con le varie relazioni, poi aprire Visual Studio, e nel caso dovessimo utilizzare Entity Framework aggiungere al nostro progetto un file con estensione .edmx. Utilizzando un approccio Model-First, apriamo immediatamente Visual Studio 2010 Beta 2 e creiamo un nuovo progetto console (ad esempio) che potremmo chiamare con molta fantasia EF2Features:

image

Aggiungiamo al nostro progetto un nuovo item di tipo ADO.NET Entity Data Model che potremmo chiamare PersoneEntiModel (di conseguenza verrà generato il file PersoneSocietaModel.edmx)

image

Dopo aver fatto click su “Add” verrà visualizzato un Wizard attraverso il quale possiamo scegliere se creare un modello a partire da un database o  partire da un modello vuoto, scegliamo la seconda opzione:

image

Bene, a questo punto, possiamo trascinare dalla casella degli strumenti presente (generalmente) a sinistra di Visual Studio due item Entity nel nostro designer, che chiameremo Persona ed Ente, assegnando rispettivamente le proprietà Nome, Cognome, ed Indirizzo a Persona, Nome e Sigla ad Ente. Per default le due entità presentano una proprietà Id di tipo Int32, le quali sono anche chiavi (Entity Key). Piccola osservazione: la proprietà StoreGeneratedPattern è per default impostata su none: questo vuol dire che il valore della chiave non verrà in alcun caso (insert or update) recuperato dal server quando verrà chiamato il metodo SaveChanges. Impostiamo invece il valore della proprietà su Identity: in questo caso si assume che il valore della chiave verrà recuperato durante il primo inserimento, successivamente si assume che il valore non cambierà. Maggiori dettagli sono disponibili su: http://msdn.microsoft.com/en-us/library/bb738536(VS.100).aspx

image

A questo punto non ci resta che creare l’associazione tra Persona ed Ente: sempre dalla Toolbox, selezioniamo l’item Association e colleghiamo le nostre due entità, specificando, tramite la finestra delle proprietà, relativamente a Persona ed Ente che agli estremi dell’associazione troveremo una collezione di oggetti, secondo del verso di lettura, di tipo Persona o Ente. 

image image

A questo punto non ci resta che creare il nostro database. In “Server Explorer” facciamo click su “Data Connections” e poi “Create New SQL Server Database…” (in alternativa possiamo utilizzare i tools a riga di comando….):

image image

Dopo aver create il nostro database, passiamo alla generazione dello script da utilizzare per la creazione: tasto destro del mouse in un punto del  designer, e dal menu contestuale “Generate Database Script from Model….”:

image

Visual Studio genererà uno script DDL (Database Defintion Lanaguage) da utilizzare per creare le tabelle del nostro DB:

image

Dopo aver premuto Finish, nel nostro progetto verrà aggiunto il file DDL (PersoneEntiModel.edmx.sql) generato che può essere eseguito: direttamente da Visual Studio, tramite SQL Server Management Studio o tool da rigo di comando. In questo caso ho optato per la prima possibilità. Dopo l’esecuzione dello script, espandendo il nodo tables nel “Server Explorer”, otteniamo quanto segue:

image 

Notiamo che per soddisfare la relazione molti-a-molti tra Persona ed Ente è stata generata una terza tabella PersoneEnte (tabella d’associazione). Per verificare ulteriormente il risultato prodotto possiamo creare un nuovo diagramma per meglio visualizzare la relazione creata tra le tabelle:

image

Soddisfacendo gli obiettivi preposti.

Questa è solo una delle novità introdotte con la nuova versione dell’ Entity Framework V.2, tra cui: “POCO Templates” e supporto per il Test-Driven-Development.

posted @ sabato 2 gennaio 2010 11.57 | Feedback (4)
News

View Pietro Libro's profile on LinkedIn

DomusDotNet
   DomusDotNet

Pietro Libro