Aggiungi proprietà alla classe POCO in fase di esecuzione

Question

Ho selezionato ServiceStack OrmLite per il mio progetto che è un'applicazione orientata ai dati pura. Sono disposto a consentire all'utente finale di creare i propri tipi di oggetto definiti in un formato XML che verrà utilizzato per generare classi in fase di esecuzione utilizzando CodeDOM.

Definirò anche alcuni oggetti "di sistema" richiesti dall'applicazione (ovvero User) ma non posso prevedere tutte le proprietà che l'utente finale utilizzerà e pertanto sto cercando un modo per consentire di estendere le classi che creo in tempo di progettazione. Esempio muggito utente

public class User 
{ 
    public Guid Uid { get; set; } 
    public String Username { get; set; } 
    public String Password { get; set; } 
} 

La fine vuole avere un Email ed un Address. Egli deve essere in grado di aggiungere le 2 proprietà alla classe superiore e tutta la classe sarà (che comunque può essere utilizzato da OrmLite, in quanto consente di sovrascrivere:

public class User 
{ 
    public Guid Uid { get; set; } 
    public String Username { get; set; } 
    public String Password { get; set; } 
    public String Email{ get; set; } 
    public String Address { get; set; } 
} 

So che ci potrebbe essere un rischio di fare quindi per arrestare il sistema (se la classe è già istanziata), quindi sto cercando il modo migliore per evitare questo problema e imitare il bisogno.

Answer 1

Sembra che ci siano due parti in quello che stai facendo qui. È necessario creare i tipi dinamicamente per supportare le proprietà aggiuntive. È inoltre necessario assicurarsi che non si finiscano mai con tipi duplicati nell'AppDomain, ad esempio due diverse definizioni di User.

tipo runtime generazione

Le varie indicazioni già fornite maniglia come creare i tipi. In un progetto, avevamo qualcosa di simile. Abbiamo creato una classe base con le proprietà principali e un dizionario per memorizzare le proprietà di "estensione". Quindi abbiamo utilizzato Reflection.Emit per creare un tipo derivato con le proprietà desiderate. Ogni definizione di proprietà viene semplicemente letta da o scritta nel dizionario nella classe base. Poiché Reflection.Emit comporta la scrittura di codice IL di basso livello, all'inizio sembra complesso. Abbiamo scritto alcune classi derivate campionarie in un'altra libreria di classi e le abbiamo compilate.Questi erano esempi di ciò che avremmo effettivamente dovuto ottenere in fase di runtime. Quindi abbiamo usato ildasm.exe per vedere quale codice ha prodotto il compilatore. Ciò ha reso abbastanza facile capire come possiamo generare lo stesso codice in fase di runtime.

evitare le collisioni namespace

La seconda sfida è quella di evitare di avere i nomi dei tipi duplicati. Abbiamo aggiunto un guid (con caratteri non validi rimossi) al nome di ciascun tipo generato per assicurarci che non sia mai successo. Difficoltà facile, anche se non so se potresti farla franca con il tuo ORM.

Se si tratta di codice server, è necessario considerare anche il fatto che gli assembly non vengono mai scaricati in .NET. Quindi, se generi ripetutamente nuovi tipi in fase di esecuzione, il tuo processo continuerà a crescere. Lo stesso accadrà nel codice client, ma potrebbe trattarsi di un problema minore se non ci si aspetta che il processo venga eseguito per un lungo periodo di tempo.

Ho detto che i gruppi non vengono scaricati; tuttavia, è possibile scaricare un intero AppDomain. Quindi, se si tratta di codice server, è possibile che l'intera operazione venga eseguita nel proprio dominio dell'app, quindi eliminarla in seguito per assicurarsi che i tipi creati dinamicamente vengano scaricati.

Answer 2

Perché non utilizzare una coppia di valori chiave per tutte le sue proprietà o almeno quelli dinamici?

http://msdn.microsoft.com/en-us/library/system.collections.hashtable.aspx

Puoi farlo nel modo in cui stai descrivendo con Reflection ma richiederà un risultato in termini di prestazioni, in questo modo consentirai anche la rimozione delle proprietà.

Answer 3

Il progetto a cui sto lavorando ha un requisito simile. Abbiamo un sistema già in produzione e disponeva di campi di aggiunta delle richieste del client.

Abbiamo risolto questo problema aggiungendo semplicemente una proprietà CustomField al nostro modello.

public class Model: IHasId<Guid> 
{ 
    [PrimaryKey] 
    [Index(Unique = true)] 
    public Guid Id { get; set; } 

    // Other Fields... 

    /// <summary> 
    /// A store of extra fields not required by the data model. 
    /// </summary> 
    public Dictionary<string, object> CustomFields { get; set; } 
} 

L'abbiamo usato per alcune settimane senza problemi.

Un ulteriore vantaggio che abbiamo riscontrato è che ogni riga poteva avere i propri campi personalizzati in modo che potessimo gestirli per record invece di richiederli per ogni record.

Answer 4

Controlla il ExpandoObject, che fornisce un supporto dinamico per le lingue per fare qualcosa di simile. Puoi usarlo per aggiungere proprietà aggiuntive ai tuoi POCO in fase di runtime. Ecco un collegamento sull'utilizzo delle funzionalità DLR di .NET: http://msdn.microsoft.com/en-us/library/system.dynamic.expandoobject%28v=vs.100%29.aspx