NHibernate avvio lento, il caricamento condizionale di HBMS e “riferimenti associazione di classe mappata”

Question

Sfondo

Abbiamo diversi progetti / applicazioni in esecuzione fuori lo stesso modello. Tutti hanno le loro uniche entità / tavoli, ma condividono anche 1 specifica, comune entità / tabella. Cioè Entità richieste dall'applicazione A, non sarà mai richiesta dall'applicazione B, tranne tavola comune, e viceversa. Ora il tavolo comune ha relazioni con le tabelle di applicazione di A, così come per le tabelle di applicazione di B. Le cose si fanno piuttosto lento durante il caricamento di un gran numero di HBMS, quindi abbiamo implementato un sistema che solo carica le HBMS richiesti dall'applicazione attualmente in esecuzione.

Il problema

In applicazione A, quando ormai si accede al comune tavolo / entità, in questo modo:

session.Linq<CommonEntity> ().Where (...);

Si ottiene la seguente eccezione

  

NHibernate.MappingException:   Associazione dei riferimenti alle classi non mappata:   (Entità applicazione di B)

Speravo NHibernate si romperebbe solo se esplicitamente cercato di tabelle l'accesso alle applicazioni di B tramite i rapporti dalla entità comune, e che, di conseguenza, non sarebbe rompere perché non abbiamo mai farlo dall'applicazione A. Ma, ahimè.

Domanda

C'è un modo per configurare NHibernate per ritardare la validazione di una mappatura rapporto fino a quando vi si accede?

Facciamo utilizzare lazy loading.

Answer 1

La configurazione è un'operazione una tantum, e la configurazione di deve essere coerenti al 100% quando si genera il SessionFactory.

Se è ancora troppo lento per voi, la configurazione può essere serializzato. Vedere http://github.com/ayende/Effectus/blob /master/Effectus/Infrastructure/BootStrapper.cs

Answer 2

Non so di un modo per ritardare la convalida, ma io non la penso così.

Tuttavia forse c'è un'altra opzione. Si potrebbe provare a utilizzare un insieme separato di file di mappatura per ciascuna delle applicazioni. Ogni set contenente solo i soggetti necessari per l'applicazione e la tavola comune.

Il file di mapping per la tabella comune non deve includere le colonne che creano le relazioni con tabelle appartenenti alle altre applicazioni.

Quindi, ogni applicazione ha una propria serie coerente di entità e sarebbe solo ignorare le colonne non mappate.