La situazione è che ho una tabella che modella un'entità. Questa entità ha un numero di proprietà (ciascuna identificata da una colonna nella tabella). Il fatto è che in futuro avrei bisogno di aggiungere nuove proprietà o rimuovere alcune proprietà. Il problema è come modellare sia il database che il codice corrispondente (usando C#) in modo che quando appare una tale occasione sarebbe molto facile semplicemente "avere" una nuova proprietà.Generics e database - un problema di progettazione
All'inizio c'era solo una proprietà, quindi avevo una colonna. Ho definito la proprietà corrispondente nella classe, con il tipo e il nome appropriati, quindi ho creato stored procedure per leggerlo e aggiornarlo. Poi arrivò la seconda proprietà, rapidamente copia-incollava, cambiava nome e tipo e un po 'di SQL ed eccolo lì. Ovviamente questo non è un modello adatto per il futuro. A questo punto alcuni di voi potrebbero suggerire un ORM (EF o altro) perché questo genererà automaticamente SQL e codice ma per ora non è un'opzione per me.
Ho pensato di avere solo una procedura per leggere una proprietà (per nome della proprietà) e un'altra per aggiornarla (per nome e valore) poi alcune procedure generali per leggere un mazzo o tutte le proprietà per un'entità nella stessa istruzione . Questo può sembrare facile in C# se si considera l'uso di generici, ma il database non conosce i generici quindi non è possibile avere una soluzione tipizzata forte.
Mi piacerebbe avere una soluzione che sia "fortemente tipizzata possibile", quindi non ho bisogno di fare molti casting e analisi. Definirei le proprietà disponibili nel codice in modo da non indovinare cosa hai a disposizione e utilizzare stringhe magiche e simili. Quindi il processo di aggiunta di una nuova proprietà nel sistema significherebbe solo aggiungere una nuova colonna alla tabella e aggiungere una nuova "definizione" di proprietà nel codice (ad esempio in un enum).
Perché non puoi usare l'EF? I geni di Microsoft hanno già capito e fatto un sacco di lavoro per voi in questo senso. Non oso vederti reinventare la ruota. – Jay
Sì, non capisco perché è necessario evitare un ORM. (Inoltre, non ho idea di cosa abbia a che fare C# generics con questo) –
Sono d'accordo, ma EF è un po 'più avanti per quanto riguarda l'architettura, quindi non posso ancora usarlo. – CyberDude