Attualmente sto sviluppando un'applicazione di e-commerce piuttosto ampia che gestisce più campi aziendali diversi. Come ogni applicazione di e-commerce, abbiamo un Concetto chiamato Ordine che ha uno o più OrderItem .
Dato che copriamo più campi aziendali i OrderItems devono memorizzare informazioni diverse in base al campo commerciale che il cliente ha inserito, attualmente viene fatto utilizzando l'ereditarietà delle classi sull'applicazione- Ereditarietà di tabelle singole e singole nella parte del database.
Ecco un esempio rapido e molto semplificato:
class OrderItem {
int amount;
int created_at;
int order_id;
}
class ElectronicOrderItem extends OrderItem {
string brand;
string description;
}
class RentalOrderItem extends OrderItem {
date startDate;
date endDate;
enum type;
}
La tabella OrderItem ora contiene tutti i campi di tutte le sottoclassi nullable se non per il tipo specifico. Sembrava una buona idea quando l'applicazione è iniziata qualche anno fa, ma ora è molto maldestra, con molte colonne nullable ~ 75.
Ora sto cercando di capire il modo migliore per ridefinire questa parte di codice con la prospettiva che l'applicazione possa essere suddivisa in parti diverse (campi aziendali) molto probabilmente.
I miei attuali approcci sarebbero uno dei seguenti:
-
utilizza CTI supportato dall'ORM che stiamo utilizzando e crea una tabella per ciascuna sottoclassi di ordine-item.
-
crea entità completamente nuove
come:
class ElectronicOrderItem {
OrderItem item;
string brandname;
string description;
}
Non sono sicuro di quale opzione sarebbe migliore, soprattutto se si pensa al fatto che il team sta crescendo e l'applicazione potrebbe essere suddivisa in singoli servizi nei prossimi anni.