2010-03-12 10 views
5

È consigliabile creare una versione più leggera di un'entità in alcuni casi solo per motivi di prestazioni che puntano alla stessa tabella ma con un minor numero di colonne mappate. E.g Se ho una tabella contatti con 50 colonne e in alcune delle entità correlate che potrebbero essere interessate alla proprietà FirstName e LastName, è una buona idea creare una versione leggera della tabella Contact. Per esempio.Utilizzo della versione Lite di Entity in nHibernate Relations?

public class ContactLite 
{ 
    public int Id {get; set;} 
    public string FirstName {get; set;} 
    public string LastName {get; set;} 

} 

Inoltre è possibile mappare più classi sulla stessa tabella?

risposta

4

Non è una buona idea. Invece, mappare sempre la classe completa e creare quelli più piccoli che è possibile proiettare utilizzando Transformers.AliasToBean o LINQ.

Un esempio di quest'ultimo:

var lightContacts = (from contact in session.Linq<Contact>() 
        where contact.Country = "Argentina" 
        select new LightContact 
          { 
           Id = contact.Id 
           FirstName = contact.FirstName, 
           LastName = contact.LastName 
          }) 
        .ToList(); 

Questo selezionerà solo i tre campi dal DB, anche quando il filtraggio da uno diverso.

Vale la pena notare che, con LINQ, è anche possibile utilizzare un tipo anonimo per selezionare qualsiasi proiezione desiderata senza creare altri tipi o mappature.

+0

Voglio utilizzare principalmente per le relazioni. Se ho una relazione Many-2-One, allora non voglio che carichi 50 colonne. – Amitabh

+0

Sempre lo stesso caso. Per impostazione predefinita, molti-to-one vengono caricati come proxy utilizzando la chiave primaria e non verranno caricati affatto se li si esclude come sopra. –

+0

Sfortunatamente sono su nHibernate 1.2 con WCF e il caricamento Lazy non è un'opzione con me. Quindi tutto è impaziente. – Amitabh

5

Non associare più classi alla stessa tabella. L'ho provato una volta e sebbene funzionasse per quello che stavo facendo, sono sicuro che mi avrebbe morso più tardi. È meglio usare le proiezioni per popolare le classi "leggere".

1

Ho utilizzato questo approccio per la gestione di un'entità senza campo BLOB (solo per la gestione delle relazioni, ecc.).

Ho avuto alcuni problemi per quanto riguarda il polimorfismo implicito, il che significa che ho avuto questa configurazione:

classe ImageWithData pubblico: Immagine

L'eredità fatta NHibernate caricare un ImageWithData in un secondo andata e ritorno ogni volta che decisi direttamente un'immagine (non se correlato con BelongsTo o HasMany).

C'è un'opzione in NHibernate per disabilitare questo comportamento, chiamato polymorphism = "esplicito" che si specifica sulla propria classe base (nel mio caso, Immagine).

Se nel tuo caso il design non è corretto, non lo so, tutto dipende dal motivo per cui è necessario alleggerire le tue entità.

Problemi correlati