Utilizzeresti NHibernate per un progetto con un database legacy, che è parzialmente fuori dal tuo controllo?

Question

Per me la risposta è attualmente: No, userei iBatis, perché NHibernate è un problema, quando il modello di database e il modello di oggetti non sono sincronizzati. Se non ho il pieno controllo del database, finisco con molto lavoro.

Perché lo chiedo?

Bene, prima di tutto: non ho mai usato NHibernate. Lo so solo dalla superficie. Ho letto dei vantaggi di iBatis per i database legacy.

Secondo: recentemente ho avuto una discussione con qualcuno che ha lavorato con Hibernate (jep, senza "N" prima di Hibernate). Mi ha detto che i framework ORM sono ora piuttosto avanzati e hanno sostenuto Hibernate. Dato che non ero interessato a NHibernate, non ho tenuto traccia dei recenti sviluppi.

Forse è tempo di ripensare la mia risposta, oppure no?

Answer 1

iBatis è certamente facile da mappare oggetti su sistemi di database legacy.

Più recentemente NHibernate 1.2 e 2.0 hanno un set di funzionalità che potrebbe farti ripensare iBatis.

NHibernate funziona con chiavi composite, che possono verificarsi frequentemente in database meno recenti, non sono sempre piacevoli con cui lavorare ma il supporto è disponibile per questo.

NHibernate può utilizzare Stored procedure per operazioni CRUD su entità, anche viste di database.

Le raccolte possono essere stored procedure personalizzate o query SQL. Le raccolte possono utilizzare l'attributo property-ref quando la relazione Chiave esterna non viene mappata direttamente sulla chiave primaria dall'altro lato.

Alcune di queste funzionalità potrebbero togliere le prestazioni / la potenza di Nhibernate, ovvero il caricamento lento con proprietà-ref non funziona (affatto?), ma nella maggior parte dei casi ci sono ragioni per questo.

Altri punti: (che non sono realmente correlati al database legacy ma possono comunque aiutare a decidere una scelta tecnologica)

La comunità Nhibernate appare molto più ricca di iBatis. Sono su entrambi gli elenchi e il volume di supporto per NHibernate è piuttosto elevato rispetto al gruppo iBatis. Quindi il supporto dovrebbe essere più semplice.

Inoltre, esiste una quantità crescente di strumenti contrib / di terze parti per NHibernate. Cose come The NHibernate Profiler, Nhibernate Query Analyzer, NHibernate Contrib, Fluente NHibernate per citarne alcuni.

Forse puoi ampliare i vantaggi che ritieni abbiano attualmente iBatis. NHibernate è stato sicuramente molto attivo di recente e ha acquisito molte nuove funzionalità, molte delle quali aiutano negli schemi legacy / difficili da modificare.

E per rispondere alla domanda, sì, usiamo NHibernate con database legacy che hanno relazioni terribili, chiavi composte, relazioni interrotte. Abbiamo ancora una piccola quantità di codice basato su iBatis. Tuttavia non scriviamo più codice iBatis.

Answer 2

Sì, considera NHibernate. È il gold standard per un motivo. Ho sentito che iBATIS supporta possibilità di mappatura folli, ma con IUserType di NHibernate puoi mappare qualsiasi cosa, anche colonne davvero strane.

@Ahmad, il punto centrale di ORM è impedire uno stretto accoppiamento tra i tuoi oggetti e il tuo schema. Se hai questo problema, lo stai facendo male.

Inoltre, con NHibernate ci sono molte opzioni per query personalizzate, proprietà della formula e procedure memorizzate. HQL è estremamente potente e Criteri è flessibile.

Penso che farai un cattivo servizio ai tuoi clienti se almeno non aumenterai NHibernate.

Answer 3

Sto usando nHibernate in un'applicazione esistente. Lo uso per tutti i nuovi sviluppi, non ho intenzione di eseguire il porting delle cose esistenti o non esiste un motivo convincente, ma per le nuove cose sul progetto funziona alla grande.

Se stai per eseguire il porting del codice, dovresti essere in grado di cambiare il database per adattarlo meglio al tuo modello di dominio, senza molto impatto (a seconda di quanto il tuo database è leale, cioè chi lo accede). La modifica del modello di dominio avrebbe comunque un impatto sull'applicazione.