Newsgroup: it.comp.lang.visual-basic
Titolo: [.NET] Entity Framework - Code First.

Ciao a tutti.
Da pochi giorni sto provando questo interessantissimo aspetto del FW.
L'intenzione ovviamente sarebbe quella di gestire la base di dati su cui poggia la mia applicazione, seguendo le ORMe delle classi. Premetto che non l'ho mai fatto; ho sempre  usato i DataSet.
Ho creato l'EDM e corretto le imperfezioni che mi venivano evidenziate. In seguito, utilizzando il "Generatore di EF 5.x DbContext" di VS 2012, ho ottenuto le classi relative alle tabelle contenute nel DB. E ora?!
Probabilmente pretendevo troppo nell'aspettarmi che mi generasse anche i vari metodi per le operazioni CRUD. Sbaglio?
Insomma, mi sarebbe sufficiente qualche link per prendere la strada giusta.
Basta POCO :-D

Ciao Fabrizio,

se hai usato l'EDM(x) non stai usando Code First, non esistono metodi 
crud, ma esiste il (Tuo)DbContext, con tutti gli ORM funziona piï¿œ o 
meno allo stesso modo.
 
Un consiglio spassionato, se vuoi usarlo bene e non farti del male usa 
code first e pensa prima solo alle classi e non al db, il db ï¿œ una 
conseguenza di come hai disegnato le classi.
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 conseguenza di come hai disegnato le classi.
Sto lavorando su un DB pre-esistente Mauro. La vedi dura?
Dato che come ho scritto non ho idea di come procedere, avresti qualche indicazione da darmi in tal senso?
Grazie 1.000.

 Grazie 1.000.


> nessuna :-) non sono un gran fan degli ORM :-P
Attendevo la tua risposta e ora mi hai fatto crollare il codice addosso :'(
Quali alternative agli ORM mi consiglieresti allora?


Per correttezza, ti informo che ho postato la domanda sugli ORM su MSDN ;-)

Ciao Fabrizio,

gli orm :-) sono una cosa fenomenale, ma vanno usati con cognizione di 
causa e senza farsi prendere la mano.


> gli orm :-) sono una cosa fenomenale, ma vanno usati con cognizione di 
Ah non credo che farò cose troppo complicate :-D
 
Scusa, su MSDN mi hanno scritto (forse avrai letto) che i Dataset sono obsoleti, a favore appunto degli ORM. Esiste una terza alternativa?
Immagino tu intuisca che non è mia intenzione essere polemico. Vorrei avere il parere di un professionista.
Grazie.

 obsoleti, a favore appunto degli ORM. Esiste una terza alternativa?
 
facciamo le persone serie e dimentichiamoci per un attimo di alcuni 
personaggi che sparano cazzate sui Forum MSDN.
 
Gli ORM risolvono fondamentalmente due problemi:
 
- ti evitano di cablare codice SQL (sottoforma di stringhe) nel codice;
- ti risolvono l'annoso e rognoso problema di:
   * identity map
   * unit of work
 
Ora il Data Set implementa un patttern che si chiama active record e ci 
sono fior di toolkit che usano questo pattern, ma nessuno dei due 
risolve i problemi di cui sopra, che ovviamente non ci sono in tutte le 
applicazioni, quindi non è detto che debbano essere risolti.
 
il primo problema è un vero problema? A casa mia no, soprattutto se usi 
un ORM che ha un supporto limitato (o non ce l'ha) per Linq, come ad 
esempio NHibernate che ha un buon provider linq ma che non ti permette 
di fare tutto. Quindi o il query provider risolve tutte le situazioni o 
il primo non è comunque un problema.
 
C'è poi il grosso problema di fare una cosa del genere:
 
var customers = from c in myContext.Customers
                where c.Country == "Italy"
                select c;
 
foreach( var customer in customers )
{
   var validAddresses = customer.Addresses.Where( a => a.IsValid );
}
 
quante query produce?


Grazie Mauro.

 Grazie Mauro.
 
Se posso e con il medesimo spirito, ti domanderei che approccio preferisci per la gestione dei dati. Immagino che dipenda dal contesto, ma potendo scegliere?

Ciao Fabrizio,

da un minimo di due modelli in su, in base ai casi d'uso. Tendo ad 
avere un *solo* modello per la scrittura, i "classici" aggregati di 
DDD, e n modelli stupidi (quindi solo dati piatti) per la lettura.
 
Questo, pur partendo da un'apparente complicazione (hai molto più 
classi da manutenere) porta alla lunga ad una notevole semplificazione:
 
- gli aggregati nella stragrande maggioranza dei casi vengono 
"caricati", per poi eseguirci delle operazioni, per *id*, quindi con la 
query più stupida del mondo (e quindi ti chiedi anche se ti serve un 
ORM in questo caso, e comunque spesso la risposta è si se il db è un db 
relazionale), siccome poi gli aggregati sono autocontentui, escludi a 
priori (anche qui nella stragrande maggioranza dei casi) i problemi 
derivanti dalle join che un ORM è molto bravo a nascondere, con effetti 
devastanti;
 
- i modelli in lettura sono dei meri DTO, fine, tante forme quanti sono 
i casi d'uso, non scriverai mai su un modello in lettura ergo decadono 
la maggior parte vantaggi che un ORM porta con se e ti rimane soltanto 
la rognosità del mapping, in questo caso ci sono comunque gli ORM o i 
"nuovi" micro-ORM (Simple.Data, PetaPoco, Dapper, etc..) che risolvpono 
egregiamente il problema.
 
è un discorso lunghissimo e per certi complesso, che richiede un cambio 
di prospettiva non da poco, ma ne vale la pena.


Di nuovo grazie.