Durante il mio viaggio nel mondo degli ORM mi sto soffermando molto su LINQ To SQL e NHibernate e come strutturare un 3Tier con questi. NHibernate è tutt'altra bestia e come sappiamo tutti è infinitamente più potente rispetto a LINQ To SQL e rende lo sviluppo con Persistence Ignorance assolutamente semplice. Tuttavia, ci sono comunque delle cose che mi fanno preferire LINQ To SQL per molti scenari.
E-Commerce: un tipo di applicazione come questa necessita di query che vanno per il 95% a consultare il database e per il restante 5% a scrivere. Applicazioni del genere hanno un modello ad oggetti abbastanza semplice e non hanno bisogno di meccanismi di persistenza troppo complessi perchè spesso gli oggetti hanno un mapping 1:1 con le tabelle del db. In questi casi non scomoderei mai NHibernate perchè sarebbe come sparare con un cannone per colpire una zanzara, mentre LINQ To SQL esprime il suo massimo potenziale in questi scenari.
Community: una community ha forum, blog, articoli, script tutti riconducibili ad un modello a oggetti anche qui estremamente semplice. Ad esempio, un articolo ed un post sul forum o su un blog hanno molto in comune (Autore, data, soggetto, testo, ecc). Anche qui, vale lo stesso discorso per la categoria precedente meglio LINQ To SQL.
Gestionali: qui il discorso si complica; con questi tipi di applicazione e con l'avvento di ajax capita spesso che si possano creare maschere con tantissimi dati dentro ed un commit finale che deve persistere grafi complessi. In questo caso la scelta tra uno o l'altro dipende da quanto il mapping 1:1 imposto da LINQ To SQL sia accettabile. Io opterei per NHibernate quando la cosa è troppo gravosa mentre in altri casi LINQ To SQL è un'ottima scelta.
Le considerazioni che ho fatto, ovviamente, tengono conto solo delle problematiche relative al mapping senza tenere in considerazione prestazioni, tipo di database, supporto degli editor, ed altro ancora.
Detto questo, viva LINQ To SQL viva NHibernate, viva il mapping manuale, viva le applicazioni che funzionano :D.
Stay tuned...
Detto questo, viva LINQ To SQL viva NHibernate, viva il mapping manuale, viva le applicazioni che funzionano.
LOL
Quando si dice politically correct
Non è che hai ambizioni politiche?
Risposta Seria:
Non è questione di politically correct, è questione che se uno scrive un'applicazione che funziona e va a dovere per me può scriverla anche in COBOL; basta che soddisfi cliente e produttore e tutto è a posto.
Risposta mia:
Mi consenta... tra poco scenderò in politica con il mio nuovo motto, "chiù pilo pe tutti"
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Io penso che la scelta dell'uno o dell'altro sia da effettuare in funzione delle scelte architetturali: se la scelta è ricaduta su Active Record, Linq 2 SQL o CastleProject sono, ovviamente, la scelta "naturale". NH, invece, è un O/RM e quindi è orientato alla persistenza di un Domain Model. Ne avevo parlato qui: http://blogs.ugidotnet.org/pape/archive/2007/06/12/linqvslinq.aspx
Modificato da andysal il 25 novembre 2007 23.03 -
Continua »»» | Rispondi »»»