nHibernate, una soluzione n-Tier + richiesta di consulenza

Ho la possibilità di sviluppare un progetto leggermente complesso e ho studiato i vari approcci che posso utilizzare per affrontare questo progetto. In genere avrei corso con il tradizionale approccio a 3 livelli, ma dopo aver passato un po 'di tempo a guardare le varie opzioni ho capito che una specie di ORM potrebbe essere più adatta e sto considerando la possibilità di ibernazione. Tuttavia, sto cercando alcune indicazioni sull'implementazione di nibernate e in particolare su come strutturare i miei BL e DAL in concomitanza con nHibernate.nHibernate, una soluzione n-Tier + richiesta di consulenza

Con nHibernate vorrei creare i miei oggetti (o DTO?) E utilizzare i metodi nibibli per le mie interazioni CRUD tutto nel mio DAL. Ma quello che non riesco a capovolgere è che gli oggetti definiti nel DAL probabilmente si troverebbero meglio all'interno del BL, cioè dove la validazione e altre cose possono essere eseguite facilmente, e io uso solo il DAL dai vari ObjectFactory/ObjectRepositories . Sfortunatamente sembra che attraverso i numerosi articoli che ho letto questo non sia menzionato o sfiorato e sono un po 'confuso.

Qual è il metodo di implementazione più accettato o più semplice quando si utilizza nHibernate in un sistema a 3 livelli? In alternativa, qual è il metodo convenzionale di esporre gli oggetti attraverso il livello aziendale dal livello dati alla presentazione?

fonte

2010-10-20 SeanCocteau

FWIW essere molto attenti nel vostro processo decisionale in quanto potrebbe avere un impatto a lungo in esecuzione sul vostro carriera se fallisci. Avevo ben oltre un anno di esperienza con NHibernate, chiudendo 2 anni prima che avessi mai avuto un'applicazione aziendale completa in produzione utilizzando NHibernate anziché un'applicazione banale. Se si fosse presentata l'opportunità che avrei potuto farlo prima, sono sicuro che avrei avuto, ma con il senno di poi non penso che sarei stato in grado di avere successo il progetto fino a quando non ho avuto quasi 2 anni di esperienza con NHibernate . –

Quindi che tipo di gotcha sto cercando qui? L'idea di ibernare è di risparmiare tempo complessivo e di alleviare i problemi piuttosto che aumentarli. Atm, capisco che l'uso di WCF mina alcune delle caratteristiche di nHibernate ma usando il pattern di Respository e DTO si aggira, il mio piano è di definire il mio oggetto Business sul BL insieme ai file di mappatura e quindi utilizzare il pattern Respository all'interno del DAL, questo è un buon piano? – SeanCocteau

Sono abbastanza impressionato da Nhibernate, abbiamo un progetto da medio a leggermente complesso (asp.net MVC) in esecuzione su di esso ora, ma ci è voluto del tempo per ottenere l'hql giusto. (a volte abbiamo dovuto imbrogliare e usare SQL raw - a causa di una mancanza di conoscenza) ho anche usato il classico mapping/entity bindind con i vecchi skool php/asp e sql spagetti, e in altri progetti abbiamo provato ADO.NET e poi Oggetti dati Java. Ora su Nhibenrate che mi ha colpito di più. –

La mia esperienza personale con nHibernate mi ha portato a decidere che il livello di accesso ai dati diventa così sottile che non ha mai avuto senso per me separarlo dalla logica di business. Gran parte del codice di accesso ai dati è già separato in file xml (o in altri metodi distintivi come Fluent nHibernate) e poiché i join vengono gestiti in modo quasi trasparente, le query che utilizzano gli oggetti criteri sono raramente più di poche righe.

fonte

2010-10-20 16:34:09

Questo è un po 'come sto pensando che le cose potrebbero andare fuori, al momento il mio pensiero è qualcosa di simile ... – SeanCocteau

Creo i miei POCO che rappresentano i miei oggetti aziendali all'interno del livello aziendale, ad es. Cliente, Ordine, ecc. E aggiunta le mie mappature Hibernate. Quindi utilizzo il pattern IRespository creando un respository per ciascun oggetto appropriato, ad es. CustomerRespository, OrderRespository, ecc. Che astrae qualsiasi ninfibernazione che consente a WCF di passare facilmente l'oggetto? All'interno del mio livello dati includo la gestione della sessione Hibernate appropriata (attraverso un Singleton?) E la classe AbstractRepository che si occupa dei metodi nHibernate nel livello dati effettivo. – SeanCocteau

Questa è la conclusione che sto per arrivare (rapidamente) e rimane ancora il beneficio dell'estrazione del DAL, il BL ospiterà i Business Objects, i file di mappatura e i relativi Repostories – SeanCocteau

Ho il sospetto che tu stia pensando troppo a questo. nHibernate è fondamentalmente uno strumento piuttosto semplice; ciò che fondamentalmente fa è gestire la serializzazione dei tuoi record nel tuo database da e verso oggetti strutturati in modo simile nel tuo modello di dati. Questo è fondamentalmente. Nulla dice che non puoi incapsulare gli oggetti di Hibernate negli oggetti Business Layer per la convalida; va benissimo Ma comprendi che le operazioni di validazione e serializzazione sono fondamentalmente diverse; Hibernate gestisce il componente di serializzazione e lo fa abbastanza bene. Puoi considerare gli oggetti serializzabili Hibernate come effettivamente "atomici".

Fondamentalmente, ciò che vuoi è questo: nHibernate è il tuo livello di accesso ai dati. (È possibile, naturalmente, avere altri metodi di accesso ai dati nel proprio livello di accesso ai dati, ma se si intende utilizzare Hibernate, è necessario attenersi alla progettazione di base di Hibernate, ovvero oggetti semplici che eseguono una mappatura relativamente semplice del record per obiettare). Se il tuo progetto richiede l'uso di un design diverso (oggetti profondamente compositivi dipendenti da più tabelle sovrapposte) che non si adatta bene a Hibernate, potresti dover abbandonare l'uso di Hibernate; altrimenti, vai con un semplice approccio POCO come implicito da ibernazione.

fonte

2010-10-20 16:35:45

-1 wish potrei -10 per la dichiarazione " nHibernate è fondamentalmente uno strumento piuttosto semplice "questo è completamente inaccurato. La gestione delle sessioni di NHibernate è una delle relazioni più straordinariamente complesse che abbia mai dovuto affrontare nello sviluppo di software. –

e un altro -1 per affermare che dovresti abbandonare Nhibernate quando la tua progettazione richiede oggetti profondamente compositi .. Nhibernate rende questo un gioco da ragazzi rispetto a molti altri strumenti che ho provato – Noctris

@Noctris In realtà dovrei essere d'accordo su quel punto per la parola chiave Deeply con NHibernate raramente vuoi andare più di 2-3 nidificazioni in profondità negli oggetti, perché dopo di ciò la tua query sql potrebbe finire con decine di join. Questo è molto facile vedere una volta che si inizia a fare l'ereditarietà in cui un Contatto eredita da Persona e un Dipendente eredita da un Contatto, l'oggetto Persona ha una collezione di indirizzi e telefoni. A questo punto hai 5 o 7 tabelle a seconda che modifichiate le collezioni come molti-a-molti o meno. –

Ho delle app basate su NHibernate in produzione e mentre è migliore della maggior parte dei DAL, sono al punto che non potrei mai raccomandare a nessuno di usare più NHibernate. La sofisticazione necessaria per lavorare con la sessione per fare qualsiasi applicazione avanzata è semplicemente assurda. Per fare semplici app, NHibernate è molto banale per le applicazioni aziendali e la complessità è fuori dai grafici.

A questo punto ho deciso di risolvere l'accesso ai dati con 3 diverse scelte in base all'ambito, utilizzando un database di documenti (attualmente Raven attualmente) per l'applicazione in scala reale, per medie quantità di accesso ai dati utilizzando LinqToSql e per accesso banale Attualmente sto utilizzando connessioni ADO.NET raw con grande successo.

Per riferimento, queste affermazioni sono dopo che ho trascorso più di 2 anni di tempo di sviluppo utilizzando NHibernate e ogni volta che mi sono mai sentito come ho capito completamente NHibernate mi imbatterei in qualche nuovo limite o chiave inglese gigante che devo fare con.Mi ha anche portato a capire che ho iniziato a progettare applicazioni per quanto riguarda NHibernate, che è uno dei miei principali motivi per utilizzare un ORM per non avere il design delle mie applicazioni dettato dal database.

Non aver a che fare con la gestione delle sessioni con la complessità di NHibernate è stato uno dei più grandi ringraziamenti per me per il passaggio a RavenDB. Con Raven hai pochissima necessità di gestire la sessione tranne quando stai facendo un'ottimizzazione delle prestazioni estreme o lavorando con azioni batch.

fonte

2010-10-20 16:56:15

Non sono sicuro del tipo di sofisticazione di cui parli quando si tratta della sessione. Almeno per le applicazioni web ho scoperto che l'HybridSessionBuilder che puoi vedere le persone che utilizzano il Web su vari blog di ibernazione rende la gestione delle sessioni abbastanza indolore. http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/ –

Prova a implementare il modello di conservazione lungo con NHibernate in un ambiente web, dopo 2 anni che ho rinunciato e accettato non è fondamentalmente possibile con NHibernate. –

Questo ragazzo sembra pensare di averlo fatto: http://dotnetchris.wordpress.com/2009/12/18/implementing-nhibernate-long-conversation-with-no-httpmodules-or-aop-build-time-weaving/ –

Sono un fan di lasciare emergere l'architettura, ma questo è ciò che la mia architettura di partenza sarebbe simile al tipico progetto ntier asp.net mvc se lo avessi iniziato oggi utilizzando NHibernate.

Prima di tutto, proverei a tenere il maggior numero possibile di codice di dominio dal controller. Pertanto, vorrei creare un livello di servizio/facciata sul livello aziendale a cui il controller (o il codice retrostante) effettua chiamate. Vorrei suddividere i miei oggetti in due tipi: 1) oggetti con comportamento aziendale che vengono utilizzati sul lato scrittura e 2) oggetti ViewModel/DTO che vengono utilizzati per visualizzare i dati e prendere l'immissione iniziale dei dati. Questi DTO avrebbero tutte le preoccupazioni specifiche della vista come semplici attributi di convalida ecc. I DTO potevano avere i propri mapping NHibernate, oppure potevano essere proiettati usando la funzione AliasToBean di NHibernate. Verrebbero mappati agli oggetti business una volta che hanno superato il controller nelle operazioni.

Per quanto riguarda il livello di accesso ai dati, probabilmente utilizzerei NHibernate direttamente nel livello di servizio. Non userei il modello di repository a meno che non sapessi che dovevo essere in grado di sostituire l'ORM. NHibernate è già un'astrazione di persistenza. Mettere un repository su di esso ti fa rinunciare a molte funzionalità.

fonte

2010-10-20 17:05:38

"Mettere un repository su di esso ti fa rinunciare a molte funzionalità." Non sarei d'accordo con questo devotamente, implementare il modello di repository in cima ad esso è un ottimo modo per accedere banalmente alla bontà di NHibernate. Ho un blog su questa parte che è la cosa migliore che abbia mai realizzato con NHibernate. http://dotnetchris.wordpress.com/2010/03/15/creating-a-common-generic-and-extensible-nhiberate-repository-version-2/ –

Quando ho detto pattern di repository, stavo pensando più lungo le linee di un agnostico ORM. Vedo che la tua è specifica di NHibernate, quindi non stai rinunciando ad alcuna funzionalità. Userei qualcosa del genere o, più probabilmente, il modello dell'oggetto query (che è fondamentalmente un insieme di repository ultra specifici). –

miei 02 centesimi (dal momento che non v'è on-risposta-fits-all):

Il DAL dovrebbe essere solo responsabile per retrievel dei dati e la persistenza.

puoi avere una libreria contenente il tuo Modello (oggetti) che sono riempiti dal DAL, ma sono liberamente accoppiati (in teoria, dovresti essere in grado di scrivere un nuovo DAL usando un'altra tecnologia e collegarlo invece di quello di NHIBERNATE , anche se non hai intenzione di farlo)

per il cliente < -> BL talk, consiglierei seriamente views/dto's per evitare l'accoppiamento del modello con il client (fiducia, io .. sto pulendo un'applicazione come questa ed è l'inferno)

in ogni modo .. sto parlando della situazione che stiamo usando qui che segue questa struttura:

cliente (WinForms e Web) < -> Visualizza/Presenter < -> servizi WCF che utilizzano i messaggi < -> BL < -> DAL

fonte

2010-10-20 17:11:51 Noctris

nHibernate, una soluzione n-Tier + richiesta di consulenza

risposta

Problemi correlati