Commenti

Autore: Rossi MarcoInviato il: 12 nov 2008 - 10.27

Vincenzo mi aveva fatto vedere qualcosa ed era veramente valido..
Adesso però bisogna vedere come spingerà la Microsoft con le sue nuove tecnologie, sarà una bella battaglia!

Autore: alx_81Inviato il: 12 nov 2008 - 10.29

C'è da considerare sempre che questo non è un ORM, quindi non si può paragonare a NHibernate, come già qualcuno mi ha detto di recente.. Quindi vi invito davvero a provarlo..

Autore: Simone FalconiInviato il: 13 nov 2008 - 23.19

iBatis.NET sembra poco conosciuto a confronto di NHibernate. Io ho avuto modo di usarlo ormai 3 anni fa, mentre NHibernate non l'ho mai usato. Purtroppo è stata la mia prima e unica esperienza con un ORM, ma devo dire che mi sono trovato molto bene. Adesso che avrei di nuovo la possibilità di utilizzare un ORM sono molto indeciso su quale usare: se rispolverare le conoscenze che avevo e quindi iBatis, se stare su NHibernate che dicono sia più completo ma più complicato o se passare direttamente a Entity Framework. Qualsiasi consiglio sarebbe preziosissimo.
@alx 81: perchè dici che iBatis non è un ORM?

Autore: gianluca gravinaInviato il: 27 nov 2008 - 13.29

Ciao,

Ho utilizzato IBatis per un progetto Java qualche anno fa, poi ho "incontrato" hibernate ... e me ne sono dimenticato ...

Diciamoci la verità, IBatis è un datamapper con la possibilità di definire le query con cui caricare i nostri oggetti (è da tempo che non lo uso, potrei dire cavolate, corregetemi), NHibernate ti toglie anche questo problema ...

Continuo a dire a tutti quelli che mi chiedono "perché NHibernate" ... perché ci si astrae completamente dalla struttura dati, e con un Profiler sempre acceso soprattutto quando si stanno muovendo i primi passi, per evitare di caricare in sessione oggetti che non ci servono, è LA SOLUZIONE.

EF, l'ho visto poco e quel poco che ho visto (a parte il discorso di persistance ignorance) è comunque limitato.

Insomma, so di dire cose che comunque un DBA aborrerà sicuramente ... ma nel 90 % dei casi le stored procedure sono inutili, meglio focalizzarci in un buon disegno logico e fisico ... e lasciare fare le query a NH.

Spero di non offendere nessuno ;)

Autore: alx_81Inviato il: 27 nov 2008 - 15.11

Me la sono presa :-) :-) :-)

Sarei d'accordo se non avessi a che fare con database spremuti al limite, se non dovessi avere a che fare con tuning e ottimizzazioni ogni giorno. Sarei d'accordo se non pensassi all'unica interfaccia pubblica che voglio offrire come accessibile dall'applicazione (ovvero le stored procedure). Sarei d'accordo se fossi in linea con l'sql dinamico che crea..
Per le situazioni reali che mi si pongono di fronte, non rinuncerei mai alla possibilità di intervenire sul codice SQL e pià sto lontano da un SQL dinamico, più sono contento.

Tuttavia in casi diversi dal mio, appoggio parte del tuo discorso :-)
Grazie per il commento,
ciao!

Autore: gianluca gravinaInviato il: 27 nov 2008 - 15.30

hehehe il primo commento acido non ha tardato molto :)

Scherzi a parte, fermo restando che anche con NH si può decidere se utilizzare query dinamiche (lo standard soprattutto per le CRUD), o per query particolarmente critiche utilizzare delle query ad-hoc ... o ancora "meglio" (secondo i punti di vista) sp.

Detto questo, onestamente non ho mai incontrato problemi insormontabili con NH dal punto di vista delle performance (fermo restando il profiler sempre a supporto), se non per qualche procedura batch (e allora il discorso può cambiare in termini di occupazione di memoria non ottimizzata per la sessione di NH).

Insomma se qualcuno mi potesse dare un test bench, una prova tangibile, del fatto che con SP le performance sono migliori io chino il capo e lo cospargo di cenere, come dire voglio metterci il naso e non avendo a che fare con "criticità" in tal senso non mi si è mai posto il problema "meglio una sp".

Ancora, non è mia intenzione di accendere una miccia su SP vs NH, ognuno svolge il PROPRIO lavoro al meglio, e ci sono casi in cui SP "vincono" contro NH, ma nel "routinario" non vedo proprio il bisogno di creare sp (sempre e assolutamente IMHO).

Un ultimo appunto:
Tu preferisci lasciare una sola interfaccia di accesso ai tuoi dati con le sp, io addirittura con il codice, lo so, e ancora, tanti risponderanno che tanto non si fa quasi mai, ma non scrivere T/SQL equivale un domani a passare a Oracle (o chi per esso) senza dover migrare sia l'applicazione che le routine di accesso ai dati. E ancora a parte qualche sforzo fatto con VS-Database edition, trovo la gestione di tutto quello che ha a che fare con un DB un delirio, mentre TFS + Codice sono sicuramente gestibili in maniera forse migliore.

Un saluto !!!

Gianluca

Autore: alx_81Inviato il: 27 nov 2008 - 15.44

>hehehe il primo commento acido non ha tardato molto :)
no dai acido no :-)))

Non sto parlando solo di prestazioni (credimi, ho una realtà dove le stored procedure sono meglio anche in questi termini, con un elevatissimo, quasi spaventoso, numero di transazioni al minuto), ma anche di comodità, nel mio caso, nel definire un livello di sicurezza più sotto controllo, essendo dipendente dall'utilizzo esclusivo di SQL Server. In più, non ho necessità di pensare ad altri RDBMS. Poi non voglio stare a creare una diatriba per le prestazioni, perchè di idee contrastanti è piena internet a riguardo :-)

Comunque concettualmente, non posso fare altro che darti ragione, perchè se vuoi slegarti dal db, sei costretto ad affidarti ad un ORM che oltretutto ti facilita, e non poco, la vita. In più se il db è di dimensioni e traffico "normale" NH è un'ottima soluzione.
Lo stesso penso per l'ultimo appunto che mi fai.

Ti dico, io le uso e anche su DB piccoli, ma perchè per me, lavorando solo su sql server, è una best practices. In termini generici, non posso che dirti che hai ragione. Questo IBatis, che non avevo mai visto, l'ho trovato leggero e comodo.
NH l'ho sempre usato con l'sql che crea lui e non mi piaceva l'idea. Ora, se mi dici che posso anche usare SP, ancora meglio, posso riprovarlo :-)

Un saluto a te, e grazie! Questi commenti sono sempre costruttivi :-)
E ricorda che sono DBA, ma sono nato DEV.. non posso "sputare" nel piatto dove ho mangiato ahahahahah.

Autore: Vincenzo ViolanteInviato il: 02 dic 2008 - 15.44

A mio parere la più grossa discriminate sull'utilizzo di un orm o di un approccio pìù manuale è la qualità del disegno del db. Nel caso dei brownfields con cui spesso incrocio le lame un orm è di solito improponibile. Se mi fosse consentito dalla situazione il forward engineering verso il db ben vengono domain models e orm.

SQL Server ed ALM su database

Scrivi un commento

Commenti