[C#] Hibernate/NHibernate

[tomminno]

Ho un problema con NHibernate e immagino che il problema sarebbe lo stesso con Hibernate dato che non trovo una soluzione.
Ho una stored procedure che esegue delle insert e alla fine esegue un update su una tabella su cui ha precedentemente inserito.
Ho ricreato nel codice la logica della stored ma al momento dell'update finale ottengo il messaggio "Unexpected row count: 2; expected: 1". Anche se tiro fuori l'update dalla transazione ottengo lo stesso errore, le insert funzionano ma l'update no.

Inoltre ho un altro problema: richiamando direttamente la stored come NamedQuery: non riesco a trovare il modo di recuperare i valori di ritorno.

[tomminno]

Ok per l'aggiornamento è colpa dei trigger, ma cavolo perchè non hanno pensato che esistono pure loro?
A suo tempo sono stati aperti bug sia per Hibernate (2003) sia per NHibernate (2005) e sono stati considerati dei non bug.
In base a quale assurda logica lo sviluppo software deve imporre delle modifiche alla base dati sottostante?
E se questa operazione non fosse possibile?
Non esistono solo sistemi nuovi.

Resta il problema dell'utilizzo delle Stored Procedure.

[shinya]

Questi sono i motivi per cui non mi piacciono i framework ORM che vogliono fare tutto loro.
Preferisco fare le cose da me, oppure usare qualcosa di più light tipo iBatis (c'è anche per .net se ti interessa, può usare stored procedure e offre un meccanismo stile DAO anche lui... anche se è meno invasivo di hibernate).

Tutti i framework comunque richiedono troppi file xml di configurazione per i miei gusti, preferisco tenere la business logic e la parte che interagisce con il DB in classi a se stanti che mi creo da solo.

[Einstein]

Fermo restando che trovo discutibile l'utilizzo dei triggers se non in casi di auditing/logging e integrità referenziale tra db diversi.
Per l'utilizzo di NHibernate con le stored procedures, prova a vedere se questo ti può aiutare:

http://ayende.com/Blog/archive/2006/...rocedures.aspx

Per quanto riguarda l'utlizzo degli OR/M in generale, è sicuramente un approccio che può dare qualche grattacapo, ma che ritengo indispensabile in applicazioni che usano un Domain Model (http://martinfowler.com/eaaCatalog/domainModel.html) complesso.

[gugoXX]

Invece a me piacciono parecchio, e da quando li sto utilizzando la produttivita' (e la tranquillta') sono migliorate parecchio. L'XML oramai si puo' quasi sempre generare da solo, anche a partire dagli script SQL di generazione dei database.
Impagabile, davvero impagabile il poter compilare e vedere 0warning 0errors, sapendo che nella compilazione c'e' anche il controllo di tipi e di strutture per la relazione con i database.

In effetti se ci sono dei trigger e' un casino che penso quasi irrisolvibile.
Le stored procedure almeno con LINQ sono supportate. Puoi ridefinire le insert/update/delete non mediante istruzioni SQL autogenerate ma con chiamate a stored procedure esistenti. Questo intendevi?

Penso che una migrazione da un sistema classico esistente ad un ORM sia abbastanza complessa.

Piccola nota di esperienza corrente. Nel mio progetto corrente stiamo usando LINQ, e abbiamo all'inizio avuto un po' di resistenza da parte di DBA e del supporto.
Entrambi vedevano come "scary" la non possibilita' di intervento da parte loro.
Erano abiutato ogni volta che e' possibile ad effettuare modifiche direttamente alle stored procedure invece che al codice, con indubbi vantaggi. Non necessita' di effettuare il deploy su tutte le macchine, nessuna ricompilazione, nessuna interruzione di servizio, etc.
Abbiamo raggiunto un compomesso a mio avviso geniale.
Il database con le tabelle fisiche e' uno schema deciso e organizzato a priori.
Ma ogni tabella viene mappata con viste 1:1 (tranne alcuni casi di parziali denormalizzazioni).
LINQ agisce leggendo solo dalle viste, che per lui sono come tabelle, e le modifiche come insert/update/delete da queste viste vengono passate attraverso stored procedure direttamente da LINQ.
Quindi i DBA e il supporto hanno la possiblita' di cambiare la definizione delle viste e le stored procedure come vogliono. Possono aggiungere/togliere campi e tabelle, basta che alla fine vengano soddisfatte le interfaccie delle viste original.
Una cosa che si perde e' la possiblita' di reverse engineer di visual studio per costruire gli XML di definizione, perche' ovviamente le viste non hanno foreign keys o primary keys, e soprattutto non conoscono le stored procedure di riferimento per le modifiche.
Ma con l'utility grafica di VS e' ancora abbastanza semplice.

[tomminno]

Originariamente inviato da shinya

Tutti i framework comunque richiedono troppi file xml di configurazione per i miei gusti, preferisco tenere la business logic e la parte che interagisce con il DB in classi a se stanti che mi creo da solo.

Gli ORM mica impediscono la separazione della Business Logic. Servono solo per l'implementazione del DAO.
La Microsoft adesso ha tirato fuori l'Entity Framework, che nasconde tramite l'editor i file di configurazione, ma è ancora una bestia oscura e non posso usarlo nel progetto perchè necessita del .NET 3.5 SP1

[tomminno]

Originariamente inviato da Einstein

Fermo restando che trovo discutibile l'utilizzo dei triggers se non in casi di auditing/logging e integrità referenziale tra db diversi.

Nel mio caso sono usati per il log delle modifiche. In ogni caso anche se fossero usati per altro, le mie scelte di programmazione non dovrebbero assolutamente influire su quelle effettuate dai DBA.

Per l'utilizzo di NHibernate con le stored procedures, prova a vedere se questo ti può aiutare:

http://ayende.com/Blog/archive/2006/...rocedures.aspx

E' un esempio inutile perchè la stored non ha paramentri in output.

Per quanto riguarda l'utlizzo degli OR/M in generale, è sicuramente un approccio che può dare qualche grattacapo, ma che ritengo indispensabile in applicazioni che usano un Domain Model (http://martinfowler.com/eaaCatalog/domainModel.html) complesso.

Infatti, purtroppo l'ambiente Microsoft è tutto orientato ai singoli applicativi e poco allo sviluppo enterprise, anche se col .NET 3.5 SP1 hanno in parte colmato la lacuna.

[tomminno]

Originariamente inviato da gugoXX

Invece a me piacciono parecchio, e da quando li sto utilizzando la produttivita' (e la tranquillta') sono migliorate parecchio. L'XML oramai si puo' quasi sempre generare da solo, anche a partire dagli script SQL di generazione dei database.

Personalmente abbiamo dovuto scriverci un applicativo che crei le classi e l'XML, dato che in giro non c'è niente, ma è un continuo mettere le mani agli XML tutte le volte che viene fuori qualcosa di nuovo sulla struttura del DB, e chiaramente grazie alla reflection gli errori vengono fuori a runtime.

Impagabile, davvero impagabile il poter compilare e vedere 0warning 0errors, sapendo che nella compilazione c'e' anche il controllo di tipi e di strutture per la relazione con i database.

Con NHibernate? Non significa niente visto che puoi sempre dimenticarti un parametro e scoprire l'errore solo a runtime.

In effetti se ci sono dei trigger e' un casino che penso quasi irrisolvibile.
Le stored procedure almeno con LINQ sono supportate. Puoi ridefinire le insert/update/delete non mediante istruzioni SQL autogenerate ma con chiamate a stored procedure esistenti. Questo intendevi?

Con NHibernate ho risolto specificando la query da eseguire durante l'update e impostando di ignorare il conteggio delle righe.
Invece per le stored procedure manca il supporto ai parametri output, con LINQ non ho provato perchè non riesco a configurarlo correttamente, nel mio caso devo usare la SP per salvare 2 o più entità. E in ogni caso è parte del framework 3.5 che non posso usare per vincoli di progetto.

Penso che una migrazione da un sistema classico esistente ad un ORM sia abbastanza complessa.

Solo che la tecnologia evolve ma la base dati ha durata infinitamente superiore per cui gli ORM in ambito enterprise dovranno sempre fare i conti con db legacy che non possono essere toccati perchè sopra quei db si fonda già un intero mondo.

Piccola nota di esperienza corrente. Nel mio progetto corrente stiamo usando LINQ, e abbiamo all'inizio avuto un po' di resistenza da parte di DBA e del supporto.
Entrambi vedevano come "scary" la non possibilita' di intervento da parte loro.
Erano abiutato ogni volta che e' possibile ad effettuare modifiche direttamente alle stored procedure invece che al codice, con indubbi vantaggi. Non necessita' di effettuare il deploy su tutte le macchine, nessuna ricompilazione, nessuna interruzione di servizio, etc.
Abbiamo raggiunto un compomesso a mio avviso geniale.
Il database con le tabelle fisiche e' uno schema deciso e organizzato a priori.
Ma ogni tabella viene mappata con viste 1:1 (tranne alcuni casi di parziali denormalizzazioni).
LINQ agisce leggendo solo dalle viste, che per lui sono come tabelle, e le modifiche come insert/update/delete da queste viste vengono passate attraverso stored procedure direttamente da LINQ.
Quindi i DBA e il supporto hanno la possiblita' di cambiare la definizione delle viste e le stored procedure come vogliono. Possono aggiungere/togliere campi e tabelle, basta che alla fine vengano soddisfatte le interfaccie delle viste original.
Una cosa che si perde e' la possiblita' di reverse engineer di visual studio per costruire gli XML di definizione, perche' ovviamente le viste non hanno foreign keys o primary keys, e soprattutto non conoscono le stored procedure di riferimento per le modifiche.
Ma con l'utility grafica di VS e' ancora abbastanza semplice.

L'obiettivo è quello, il problema è che il database è praticamente impossibile da modificare visto le migliaia di applicativi che vi ruotano intorno.

[shinya]

Originariamente inviato da tomminno

Gli ORM mica impediscono la separazione della Business Logic. Servono solo per l'implementazione del DAO.

Mi sono spiegato male. Intendevo dire che preferisco gestirmi la separazione della logica e i DAO da solo, senza xml, ma attraverso convenzioni. Questo perchè...

Originariamente inviato da tomminno

Personalmente abbiamo dovuto scriverci un applicativo che crei le classi e l'XML, dato che in giro non c'è niente, ma è un continuo mettere le mani agli XML tutte le volte che viene fuori qualcosa di nuovo sulla struttura del DB...

...e quando xml diventa anch'esso un linguaggio di programmazione, è l'inizio della fine.