ciao a tutti
vi pongo una questione che mi sta incuriosendo, sono appena entrato nel mondo di .net e sto iniziando a imparare a scrivere web application, ora come ORM che mi consigliate?
Entity Framework o NHibernate?
Grazie a tutti
ciao a tutti
vi pongo una questione che mi sta incuriosendo, sono appena entrato nel mondo di .net e sto iniziando a imparare a scrivere web application, ora come ORM che mi consigliate?
Entity Framework o NHibernate?
Grazie a tutti
mai usato nhibernate ma posso parlare di EF. Ho usao ef dalla v.1 e ora che siamo alla v4.1 devo dire che di miglioramenti ce ne sono stati. Per prima cosa oggi si puo davvero progettare il modello prima del db e c'è il supporto all'ereditarietà in tutte le salse: sia con i campi discriminanti che table per type.
Puoi avere 3 tipi di approcci
Database first: Ideale per quelle situazioni in cui si ha gia un db o si preferisce avere il pieno controllo del database e costruirci poi su il modello di mapping.
Model first: Si parte dal modello di mapping senza avere il database e generare il DB successivamente dal modello.
Code first: Si basa sul concetto di "convention over configuration". non progetti il db, il modello di mapping ne tantomeno metti mani su file xml ma scrivi direttamente le classi che rappresentano le entita.
Nei primi due casi non hai a che fare con file xml (anche se esistono e volendo ci puoi mettere mani) perche è tutto supportato da un tool visuale (integrato in vs) che ti permette di fare piu o meno tutto.
Nell'ultimo caso non hai nemmeno bisogno del tool visuale, fai tutto in c#. Se posso dire la mia sulla filosofia "convention over configuration" su cui si basa non solol'approccio "code first" di ef ma parecchie tecnologie nuove di microsoft (ria service, asp.net mvc) devo dire che è comodissima ma bisogna sapere cosa avviene dietro le quinte ed essere consapevoli che in ogni caso i comportamenti standard possono essere riscritti o configurati a piacimento. Insomma si è operativi subito ma se si vuole il 100% del controllo sul comportamento bisogna approfondire.
qui alcuni articoli e commenti sull'eterna lotta tra i due ORM, buon divertimento.... ;-)
http://gregdoesit.com/2009/08/nhiber...formance-test/
http://ayende.com/blog/4351/nhiberna...-framework-4-0
http://blogs.teamb.com/craigstuntz/2008/07/17/37825/
http://foofish.org/blog/?p=57
http://tanveerbadar.wordpress.com/20...vs-nhibernate/
http://www.slideshare.net/klucrab/en...-vs-nhibernate
http://www.linqitalia.com/articoli/e...hibernate.aspx
http://blogs.aspitalia.com/az/post24...hibernate.aspx
________________________________
http://glucolo.wordpress.com
http://www.liveperson.com/glauco-cucchiar/
Grazie a tutti,
leggerò tutta la documentazione e vedremo quale dei due è più utile nel mio contesto
articoli di confronto fra le nuove versioni dei due prodotti ce ne sono?
ho usato entrambi
nhibernate devi settare tutto a mano
ma proprio TUTTO,a meno che tu non abbia uno di quei tool di terze parti che partendo dal db ti genera gli schemi XML e le strutture
EF, fa tutto da solo, ovvio, dipende che ci devi fare, ma alla fine il mio approccio è stato migliore in quanto se c'era un errore te lo diceva chiaramente DOVE era e perchè, in Nhibernate...sono uscito pazzo!!in quanto se sbagli un tag XML è difficile rintracciare la sorgente dell'errore!
non voglio sminuire nhibernate, fa molte cose, tante
ovviamente è stato 2 anni fa, quando i prodotti erano acerbi, ora sicuramente saranno migliorati ( e di molto presumo)
è solo la mia esperienza!
forse a qualun'altro è andata meglio con nHibernate
NN vi diro mai chi sono in realta,
tutti i miei 3D sono orfani, non insistete per farmi rispondere ai 3D aperti da me
Ciao a tutti.
@Thor0055
io non ho mai provato NHibernate, ma ti posso dire qualcosa a riguardo Di EF, nello specifico io ho utilizzato ultimamente la 4.2 disponibile in NuGet Packages.
Usando Code First mi sono trovato magnificamente, scrivi le classi per il modello dati, crei il contesto, e hai il pieno controllo di tutto il codice, controllo dell'input e degli errori compreso, e tutto nel modello stesso (IValidatableObject ... ), in modo che in qualsiasi contesto lo usi, che sia web o desktop, hai sempre la tua logica già implementata.
Secondo il mio punto di vista, però, ha senso solo se lo usi con un pattern tipo MVVM, in questo modo sfrutti veramente la sua potenza.
La mia esperienza è stata con un approccio simile al MVVM, ma non esattamente quello, infatti ho creato una specie di adattatore "universale" tra il modello e la vista (diciamo un ViewModelBase, ma senza riferimento ne al Model ne alla View), che consente di avere i comandi basilari (come caricamento, modifica, aggiunta eliminazione, ricerca avanzata, controllo degli errori ecc.) implementati con IComand equindi tranquillamente bindabili in qualsiasi interfaccia, d'altra parte, il modelllo può essere sonstituito da qualsiasi modello che eredita da DbContext. Quindi in sostanza, grazie a EF, ho potuto ottenere una nettissima separazione degli strati ma comunque mantenendo la possibilità di controllare pienamente tutto, poi ho messo tutto il una dll, e mi sono ritrovato a poter usare tutto un programma con qualsiasi intefaccia (WPF ASP.NET Silverligth Windows Form) e/o per estenderne le funzionalità senza scrivere codice aggiuntivo, e la dove serviva un qualcosa particolare (come potrebbe essere ad esempio un RFID che ha senso (o quasi!) solo in locale), mi è bastato creare i ViewModel ereditando dall'adattatore e fare l'override di ciò che mi serviva, poi per il resto bastava bindare senza riscrivere un solo evento o funzione o comunque una riga di codice!
direi voto : 9,5![]()