sicuramente solo la persona meno indicata per rispondere a quesiti di architettura.

ma rispondo lo stesso.

non mi piace.

principalmente perche lo trovo troppo verboso come la maggiorparte dei progetti derivati da java.

preferisco la mia (forse perche mia ) achitettura meno general purpose, ma più snella e trastparente.

il progetto è comunque notevole.

ciao marco

figuriamoci se posso odiare del codice...non odio la mia suocera (bhe forse lei si)

è verissimo che ti fa risparmiare del tempo( non nel rapporto 10 : 1 comunque), che è un framework notevole ma devo fare le cose come vuole lui, ma se mi piacesse come propone di farle non ci sarebbe problemi.

è solo che con la marea di codice che ho scritto in due anni, difficilemente faccio un Dal nuovo orami riuso quasi tutto, e il tempo che passo a "mappare" con NHibernate lo posso passare a cambiare il mio Dal, ma non escludo a priori di utilizzarlo.

personalmente preferisco progetti come Linq che hanno un enorme vantaggio rispetto NHibernate possono contare sull'itegrazione con il CLR, il compilatore ecc ecc, poi vediamo se ne esce una valida alternativa.

ciao marco

magari non li avrò tutti, spesso li conosco con altri nomi altri mi sfuggono ma ho quello che serve dove serve .

il miò non è un attacco a NHibernate figuriamoci, ho detto che è un progetto notevole, completo e complesso.

è un opinione personale che mi porta a preferire la realizzazione di componenti custom piccoli riutilizzabili facili da mantenere.

il Dal che utilzzo non è lontamente paragonabile a un progetto che nasce con scopi completamente diversi dal mio.

per portare un esempio quando eoni fa ero geometra se si progettava una viletta si pensava hai proprietari a dare la giusta dimensione alle loro apsettative.

bel altro approccio ha un centro commerciale, bel altra complessita ma non è detto piaccia e vada bene a tutti.

tutto quà

ciao marco

Scusa Daniele, ma francamente non riesco a spiegarmi una cosa.
A prescindere dal fatto che alcune di queste funzionalità sono disattivabili (vedi caching di secondo livello, per dirne una), ma come fanno a non servire? Mi spiego meglio:
se faccio un DomainModel per il programmino della rubrica telefonica sono un folle. Il Domain Model comporta parecchie grane, prima fra tutte il mapping sul DB, quindi lo uso quando la complessità dell'applicazione lo giustifica. Detto questo... cosa non serve?
La Unit Of Work? E come distinguo se un oggetto in memoria è stato modificato o se è stato creato ex novo?
Il lazy load? Così magari tiro su una fattura e mi trovo in memoria mezzo DB.
La identity map? così senza identity map rischio di avere in memoria due istanze differenti di un oggetto che provengono dalla stessa riga del DB.
Quello che voglio dire è che ciò che ho elencato, imho, è una serie di features quasi INDISPENSABILI per un buon DAL. E invece secondo me tanta gente pensa che un DAL sia solo una coppia di query in croce e buonanotte.
Mah... "rischio di trovare qualcosa non ottimizzato al 100%" (parliamone, tra l'altro, con NH hai due livelli di cache), però nell'altro modo rischi di creare un'applicazione piena di bug o comunque poco manutenibile.

Poi magari sbaglio io, eh...