Buongiorno a tutti,Sto studiando un po' Entity Framework 4 ed ho qualche dubbio sul mapping.Queste sono le cose che "credo" di aver capito...- Per fare un mapping "custom" (Esempio mappare l'entity Customer sulla tabella Associations o la proprieta Description sulla colonna [DESC]) devo necessariamente utilizzare l'approccio code-first- Con il file EDMX non sono obbligato ad usare le classi generate. Posso usare anche quelle scritte a mano posizionate su un assembly esterno ma perchè funzioni il mapping deve esserci corrispondenza tra i nomi cioè nome classe=nome tabella nome proprietà=nome campo
I problemi che mi vengono in mente:- Il mapping via codice mi piace meno di quello via xml (gusto personale)- Se voglio usare l'EDMX con entità già scritte a mano devo riscriverle nel designer edmxPer farla breve mi sarebbe piaciuto un approccio tipo nhibernate con in più il supporto del designer edmx.Una cosa tipo ...Ho le mie entity già scritte apro il designer le importo e tramite designer configuro la mappatura con il db(che ho costruito a mano) quindi disattivo ogni generazione di codice ed ho usato il designer solo per la mappatura (che per me non è poco).Se invece ho bisogno di una nuova entità ancora non esistente il designer mi potrebbe aiutare nella sua scrittura se si tratta di un oggetto semplice (tipo un ipotetico AddressInfo) .
Cosa mi dite di queste considerazioni? mi sono perso senza accorgermi che quello che cerco EF lo fa già oppure ho capito bene ma sono le mie esigenze ad essere sbagliate :-| ?Un saluto.
Un "presentimento" mi dice che la tua preferenza verso NHibernate è Netta! Spero che qualcuno fughi al più presto i miei dubbi magari dicendomi che ho frainteso qualche cosa. :-(Vorrei adottare EF4 come "investimento" di fiducia verso il team di ado.net e verso uno strumento incluso nel Framework...
Ciao
NH è un prodotto più maturo, anche perchè deriva da hibernate che è lo standard in java. Penso che ogni programmatore java quando si tratta di accedere ad un db consideri hibernate come prima alternativa :).
EF ha il solo vantaggio di essere incluso nel framework e sicuramente avrà supporto Microsoft, per cui magari vale la pena investirci per essere pronti per la prossima versione, oppure in generale in quelle realtà in cui non si possono usare prodotti open source.
alk.
--Blog Eng: http://www.codewrecks.com/blogBlog Ita: http://blogs.ugidotnet.org/rgmTwitter: http://twitter.com/alkampfer
Oltre alla strada che hai descritto (classi PI/POCO in un assembly, ed EDMX nell'altro), in EF ci sarebbe anche lo scenario "code only" che ti permette un mapping "fluent" delle tue classi "a la FluentNH". Il problema è che non è un approccio supportato "out of the box" da EF perché il dev team non ha fatto in tempo ad ultimarlo, e richiede quindi il download dal sito MS di un toolkit aggiuntivo, che oltretutto è ancora in stato di CTP. In ogni caso, la CTP attuale non supporta il designer quindi si tratta di scriversi in qlche modo il dominio (direttamente in C#, class designer, diagramma UML delle classi, ...) e poi mapparlo scrivendo codice fluent.
Ove l'argomento fosse di tuo interesse, ne troveresti un "embrione di esempio" in NSK, nel DAL ManagedDesigns.Nsk.Data.EF; potresti quindi partire con un mapping "POCO" supportato da EDMX, ed al momento del rilascio della RTW del toolkit "code only" sostituire i mapping. Per intenderci, è quello che facciamo noi in azienda e che sto per committare anche in NSK (potenzialmente anche oggi, devo solo aggiustare un paio di dettagli).
A questo punto, veniamo alla domanda "grossa": EF o NH? La risposta è molto semplice: hai deciso di usare LINQ come query object idiomatico? In caso affermativo, ad oggi NH non è una opzione praticabile perché il LINQ provider non è in grado di eseguire query "real world", dove per "real world" intendo: "le query che scriveresti in un applicazione reale di complessità almeno media". Puoi fare a meno di LINQ? NH è un O/RM migliore di EF4 praticamente sotto ogni punto di vista.
Concordo, il supporto a LINQ in maniera seria è attualmente il vero problema di nhibernate. Se non ti interessa LINQ perchè le tue query le fai direttametne in HQL e ti trovi bene con HQL, allora NH è il prodotto che fa per te.
Il provider LINQ della versione 3 dovrebbe essere ok, il fatto è che il provider attuale è derivato da un esperimento di ayende, lavora con ICriteria e quindi chiaramente si incontrano grossi limiti, il nuovo dovrebbe andare su HQL (ma non ho mai avuto tempo di guardare la trunk), e cmq dovrebbe fornire un buon supporto per tutte le query che puoi trovare in un'applicazione "Reale"
Andrea Saltarello:...Ove l'argomento fosse di tuo interesse, ne troveresti un "embrione di esempio" in NSK, nel DAL ManagedDesigns.Nsk.Data.EF; potresti quindi partire con un mapping "POCO" supportato da EDMX, ed al momento del rilascio della RTW del toolkit "code only" sostituire i mapping. Per intenderci, è quello che facciamo noi in azienda e che sto per committare anche in NSK (potenzialmente anche oggi, devo solo aggiustare un paio di dettagli)....
Grazie. ciao
La situazione è stata più o meno questa, Ayende ha scritto uno scheletro di linq to nh che andava su ICriteria, poi altri hanno contribuito, io avevo iniziato a metterci le mani, ma poi ho rifatto da zero supportando quello che mi serviva, anche perchè ho scelto una strada di parsing dell'albero postfissa, che è veramente tanto più semplice. Alla fine ti fermi perchè ICriteria non supporta gli having (e quindi non li puoi fare) e sul grouping è un vero casino.
Un tizio ha detto, Con ICriteria non si può, meglio fare qualche cosa che si appoggia su HQL, ma prima scriviamo il parser AST con antlr per HQL, quindi da quel poco che ho seguito, l'implementazione ufficiale di LINQ è stata spostata per la versione3, nel frattempo quella per la 2 è stata espansa, ma ha comunque molte lacune, e dato che poi non sarà quella ufficiale è stata lasciata li... questo perlomeno è quello che ricordo.
La versione linq della 3 non la ho mai guardata :( per cui non ti so dire a che punto è. La mia idea però è che per fare una cosa per bene dovrebbe andare direttamente su sql, nel senso che non mi piace che il provider linq vada su icriteria o hql e da li un altro parser crea il sql, per andare bene secondo me il provider linq deve essere alla pari di icriteria e hql un first class query language.
Ciao Giulio,
petrux:In generale, sarebbe bello poter sapere come si scrive un provider Linq. Hai pubblicato qualcosa sul blog? Hai scritto qualcosa? Hai da linkarmi qualche tutorial? (Vuoi mandarmi il codice via mail? :-p)
esistono diversi tutorial online su come creare dei provider Linq. Giusto per segnalarne un paio:
http://msdn.microsoft.com/it-it/library/bb546158.aspxhttp://blogs.msdn.com/b/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx
in generale, cercando su google la voce "create linq provider" si trova un bel po' di roba.
petrux:> Un tizio ha detto, Con ICriteria non si può, meglio fare qualche cosa > che si appoggia su HQL, ma prima scriviamo il parser AST AST? cosa sarebbe? > con antlr idem. :-)
AST sta per Abstract Syntax Tree: è la rappresentazione, in forma di albero, di un frammento di codice. Tipicamente, il "nucleo" di ogni processo di compilazione può essere suddiviso tre fasi:
(il modello è molto semplificato, spesso intervengono anche altri attori come il precompilatore in C, o il compilatore JIT in .NET, che fanno dell'altro lavoro).Antlr è un tool che permette di generare in modo automatico il Lexer, il Parser, ed i vari nodi dell'AST partendo da un file contenente una descrizione formale del linguaggio che si desidera implementare...Se ti interessa l'argomento, dà un'occhiata qui: http://edenti.deis.unibo.it/Ling/2009-2010/
Ciao,neronotte
Ineccepibile neronotte :)
Sostanzialmente si tratta solamente di esaminare un expressiontree e tradurre quello nella query. Il tutorial di mattwar è molto bello. Cmq sostanzialmente costruirsi il proprio linq provider non è una cosa da tutti i giorni, soprattutto a seconda di che livello di supporto vuoi dare.