Architettura generale con tabelle codici?

Question

Architettura generale con tabelle codici?

#1 da (2 voti)

4

Ho lavorato solo in una volta dal momento della laurea in CS. Questa è una domanda di architettura piuttosto semplice, ma non ne so di più visto che ho lavorato solo in un posto. Dove lavoro gestiamo un gran numero di tabelle di codici. Ad esempio, supponiamo di avere un sistema di vendita / ordine e di avere uno stato dell'ordine. Manteneremmo una tabella degli stati dell'ordine che sarebbe simile alla seguente:

OrderStatus:

OrderStatusId(PK TinyInt)  OrderStatusDesc(VarChar(50))  
1                         Created  
2                         Submitted 
3                         Processing
4                         Canceled
5                         Verified
6                         Complete

Quindi creiamo un'enumerazione su ogni tabella di codici. Ad esempio:

Public Enum TblSalesOrderStatus
      eosCreated = 1
      eosSubmitted = 2
      eosProcess = 3
      eosCanceled = 4
      eosVerified = 5
      eosComplete = 6
End Enum

Quindi nel nostro codice abbiamo codice come il seguente:

If OrderStatus = eosCreated OrElse OrderStatus = eosSubmitted Then
    ...do some work
End if

Su ogni schermata che creiamo, abbiamo gli ID memorizzati nei controlli (come i combobox). Non so qualcosa su questo mi ha sempre fatto pensare al suo cattivo design. Forse ho sbagliato comunque. Soprattutto quando ho iniziato a entrare in progettazione REST. volevo passare gli Id piuttosto che le descrizioni. Naturalmente questo non sembra giusto dal momento che sarei l'unico che abbia mai visto passare quel tipo di Id in un servizio REST. Quindi questo cattivo design?

Modifica:
Cercando di rendere la cosa un po 'più chiara. Le tabelle di codici sono archiviate solo in due punti: The Enum + The Database. Quando abbiamo bisogno di un nuovo ID quando inviamo un'email al nostro personale del database che crea un nuovo valore di tabella di codici per noi e ci restituisce l'ID. Quando poi metti il nuovo valore nelle nostre enumerazioni. Non abbiamo mai avuto problemi con la sincronizzazione, ma se è stato necessario eliminare i valori o modificarli in passato (l'aggiunta è semplice) è stato un problema perché è stato necessario ricompilare tutto nel sistema.

Siamo andati lungo il percorso cercando di rendere le cose semi-dinamiche (il che non funziona in ogni caso, ma aiuta in alcuni). Ci sono un sacco di esempi, ma un semplice esempio è che abbiamo un flag IsVisible in alcune delle tabelle di codici. Se vogliamo mai diventare obsoleti o rendere uno dei valori non selezionabili, impostiamo il flag IsVisible = 0. Preferiscono questo rispetto al dover cambiare codice / compile / deploy. Pensandoci penso che sarebbe preferibile averlo nella logica del buisness e testarlo (cosa che non facciamo :-() a seconda delle tue prospettive.

architecture

posta coding4fun 21.07.2012 - 03:16

fonte

1 risposta

Leggi altre domande sui tag architecture

Devo refactoring questa applicazione di rotaie? Gestione dei formati di risposta REST

score 2 · Answer 1

Non so se questo è ufficialmente "buono" o "cattivo", ma ho lavorato per un'azienda in cui abbiamo usato (e usano attualmente) questo approccio, con alcune differenze:

abbiamo avuto una tabella di codici e ogni riga è stata identificata (e indicizzata su) ["tipo di codice", "codice id"] coppia;
c'era un "tipo di master" che descriveva i tipi di codice stessi, quindi è stato facile aggiungere un nuovo tipo di codice: aggiunta una riga al tipo di codice "master" e le righe dei codici effettivi;
abbiamo avuto altre colonne in questa tabella, quindi è possibile aggiungere informazioni esterne ai codici, che sono stati utilizzati dal gestore del tipo di codice effettivo.

Non è stato utile solo per memorizzare i valori stringa per gli id di codice. Per alcuni tipi (tabelle dati, pannelli della GUI, moduli, lettere, ...) abbiamo inserito il nome della classe Java dell'handler effettivo nel record dell'archivio del codice e, quando ci siamo riferiti alla "tabella 42", abbiamo ottenuto un oggetto logico aziendale reale riempito con dati. Sì, Spring non era lì in quel momento.

Penso che questo sia fondamentalmente un buon progetto , creiamo un sistema molto modulare e una prototipazione rapida. L'unico problema con questo approccio era che una parte del "sistema" era in realtà il contenuto di una tabella dati, che non era facile da mantenere sincronizzata con i codici e le versioni delle app (abbiamo inserito i dump della tabella di codici nel sistema di controllo della versione, non è una bella cosa).

Quindi oggi non memorizzerei questa tabella in un database, ma in un file di testo semplice (json, xml, cfg, qualunque cosa), che è facile da diff (!!!) e può essere archiviato, ramificato, ecc. nel controllo della versione, direttamente collegato ai sorgenti, poiché la loro combinazione forma la versione di implementazione effettiva dell'applicazione.

Quindi nel tuo caso aggiungerei anche questo "master code store" che contiene tutti gli altri tipi di codice (se non esistono ancora) per centralizzare la gestione dei tipi, e forse raccoglierebbe molti tavoli piccoli in una singola tabella, con una colonna di tipo. Con le query indicizzate, (o anche: viste che renderebbero questo cambiamento trasparente ai codici esistenti!) Non c'è praticamente alcuna differenza di prestazioni, ma è molto più semplice mantenere una tabella di codici. Usando il tipo di master, è anche possibile scrivere uno strumento di gestione piacevole (come abbiamo fatto, e si sentiva bene: la gestione di alcuni codici a bassa priorità è stata delegata agli amministratori del client).

Inoltre, le caselle combinate non devono "conoscere" la tabella dei codici effettiva, solo l'id del tipo nella tabella comune. In pratica, una sola classe combo è sufficiente, aggiungere un nuovo tipo significa utilizzare la stessa casella combinata con il nuovo id (la conversione int / enum non appartiene all'elemento GUI, ma la logica di controllo che ascolta la combo).

Prenderò in considerazione la possibilità di generare a livello di codice i codici sorgente enum dalla tabella. Questo è un compito ripetitivo, e penso che sia abbastanza facile commettere errori qui, ma non così difficile da automatizzare. In qualche modo "proteggerebbe" anche il contenuto della tabella di codici: "toccalo solo se sei pronto a spiegare perché altri codificatori devono rifattorizzare il loro codice per usare l'enumerazione modificata ...": -)

Informazioni sul passaggio degli id: hai assolutamente ragione!

La tua logica aziendale deve sapere che hai il valore enum blahBlah nel campo AAA - questo ha un significato nel tuo contesto (il fatto che il campo AAA usi il tipo di codice 42 è anche fuori portata per la tua logica aziendale, che è un informazioni di configurazione esterna). La casella combinata è responsabile della conoscenza che l'ID 2 nel tipo 42 deve essere visualizzato come "Blah blah blah" e quando l'utente seleziona la stringa "Yippiee hoo!" è id 6 nel tipo 42, e NON dovrebbe sapere che id 6 significa enum yippieehoo per la tua logica di business! Un insieme di responsabilità totalmente diverse - e non ho ancora menzionato le versioni linguistiche, cosa lo rende ancora più evidente; -)