Dopo una ricerca di quello che il web propone, mi sono proposto di realizzare il mio Entity Framework.
Mi sono deciso di pubblicare tutto il mio processo di realizzazione, perchè sono sicuro che tanti come me si sono un po' stancati di scaricare "cose" non estensibili, di provare del codice che "se c'e' uno spazio in una cartella non va", di agganciarsi librerie che "non vanno se non siete connessi a internet".
Che cos'e' un Entity Framework
Semplicemente si tratta di un processo, che data una connessione ad una fonte dati abbia la capacità di ricostruire sotto forma di codice le classi che rappresentano lo schema dati.
Tante parole che spiegano e non spiegano, ma come al solito un esempio vale più di mille parole.
Supponiamo di aver un Db che contiene due Tabelle:
Amici
- idAmico
- idTipoAmico
- Cognome
- Nome
TipoAmici
-idTipo_Amico
-Nome_TipoAmico
-Descrizione_TipoAmico
Un entity framework che si rispetti, dovrebbe, dopo un analisi del db, fornirci come Entity:
class Amico
{
public int idAmico {get;set;}
public int idTipoAmico { get; set;}
public string Cognome {get; set;}
public string Nome {get; set;}
}
class Amici :List<Amico>
{
}
class TipoAmico
{
public int idTipoAmico { get; set;}
public string Nome_TipoAmico { get; set;}
public string Descrizione_TipoAmico { get; set;}
}
class TipoAmici :List<TipoAmico>
{
}
Ma, ci dovrebbe fornire anche qualcosa in più, ossia la classe che si occuperà fisicamente di leggere e scrivere su DB, ossia la classe che si occuperà del vero lavoro.
class AmicoAdapter
{
public int Insert(Amico item)
{
// istruzione sql per insert
}
public void Edit(Amico item)
{
// istruzione sql per update
}
public void Delete(Amico Item)
{
// istruzione sql per delete
}
public List<Amico> Select ()
{
// istruzione sql per select
{
}
Naturalmente si tratta di esempi e quindi non mi cimenterò nella scrittura approfondita del codice. Anzi, per il momento non la considero proprio.
A bene vedere e a ben comprendere un Entity Framework altro non fa che "levarci le castagne dal fuoco" ossia realizza per noi delle classi che ci serviranno per la realizzazione di un progetto.
Perchè voglio realizzare un Entity Framework
La domanda è lecita, ma la risposta non è così scontanta.
Ogni azienda, grande o piccola deve provvedere alla tutela della sua proprietà intellettuale, al valore delle proprie buone pratiche e alla qualità di ciò che fornisce e fornirà ai suoi clienti.
E' quindi un MUST to Have provvedere alla realizzazione di un qualcosa che in parte assolva o garantisca un certo livello di qualità in questo compito.
Ponetevi la questione da un livello più alto, se vi trovate a dovere realizzare un applicazione con un db da 100 tabelle, davvero il primo pensiero e di raelizzare una ad una 100 classi per le entità e altrettante 100 per le collezioni? Direte al vostro manager, capo progetto, amministratore delegato che vi ci vorranno 100 giorni solo per
realizzare il telaio della base dati ?? Sono scelte io non lo farei...
Quindi realizzo questo Entity Framework sulla base della mia esigenza, ripromettendomi però di lasciare tanto spazio libero, non solo alle interpretazioni, ma a eventuali "plugin" che potranno dare maggior beneficio a chi "sfrutterà questa base".
Chiaramente, pubblicherò la maggior parte del codice, ma mi riservo di tenere qualcosa per me...
Che cosa mi/vi servirà
-SqlExpress
-VisualStudio
-C#
-Linq
-Conoscenze di base sugli oggetti Ado.Net
-Reflection ( credo proprio che mi servirà )
-Generic ( come sopra )
-Un po di conoscenza dei principali pattern.
Che cos'e' un Entity e che cosa deve Fare
Per quel che mi riguarda un entità altro non è che una classe, il cui scopo è di contenere delle informazioni relative ad una astrazione di dati.
Con astrazione di dati intendo che al momento non so e non voglio sapere da dove provengono e perchè.
Quindi l'esempio Amico, potrebbe andare anche bene, tuttavia si tratta di un qualcosa
di troppo passivo. Contiene e non fa altro, e ciò non è corretto.
Un esempio dovrebbe chiarire meglio la situazione:
Durante un processo d'inserimento dei dati in Amico, se volessi tracciarne il contenuto, dovrei interrogare proprietà per proprietà, con Amico la cosa è presto fatta, ma difficilmente ci va così bene.
Quindi alla mia classe Amico, manca un metodo che tracci il suo cambiamento e verosimilmente un evento che ci comunichi che lo stato è cambiato.
L'Entità per il mio framework deve:
A)contenere delle proprietà che rappresentino la fonte da cui arriva,
B)contenere un metodo o un delegato che ne esegua la traccia,
C)contenere un evento che mi sappia indicare che lo stato è cambiato.
E già che ci siamo visto che sono parecchio pignolo, la mia classe, dovrà
già anche implementare i commenti come summaries, perchè a ma piace avere un prodotto completo.
In questi commenti, mi piacerebbe anche avere l'autore, la data di creazione e nominalmente la fonte di provenienza.
Tuttavia, mi sembra che la mia Entità non sia ancora del tutto completa, perchè se per esempio dovessi avere due amici con lo stesso nome e con lo stesso cognome ?
Sarebbe carino avere la possibilità di clonare l'entità già implementando il necessario per farne una copia ? no ? NO! assolutamente no. Un entità deve essere anche un filo Stupida, perchè alla fine dei conti è solo un contenitore, che al massimo ci può dire quando è pieno.
Perchè usare una lista e non una dataTable
Mi appello al 5 emendamento di uno stato che non è il mio... ma avete presente quanto pesa una dataTable ? avete provato a usare Linq su una dataTable ? è un po come se per uccidere un insetto si ricorresse ad una bomba atomica.
Quindi userò una list senza troppi complimenti.
La collezione di elementi per il mio Entity Framork:
A)sarà reso con un lista,
B)conterrà i commenti come per l'entità,
C)non avrà bisogno d'altro.
