Stato pattern vs Ereditarietà

4

Nell'immagine seguente per il Pattern di stato da Applicazione di pattern e pattern basati su domini: con esempi in C # e .NET

Sto cercando di mantenere l'entità SalesOrder nel database. Normalmente avrei una tabella salesOrder nel mio database con un campo currentState che punta allo stato corrente dell'entità.

Questa implementazione va bene in quanto esiste un'entità singola e i suoi stati contengono solo comportamenti diversi.

Tuttavia , cosa succede se devo monitorare altre proprietà per i diversi stati? Esempi:

  • Quando un SalesOrder viene annullato, devo tracciare il% cancellato% co_de, quantity , cancellationReason , cancelledBy .
  • Quando un ordine di vendita è rimborsato, devo tracciare cancellationDate , refundQuantity , refundPrice .

Quindi in pratica è come se avessi un refundFee e CancelledSalesOrder entità con attributi aggiuntivi. Lo stesso si può dire anche per gli altri stati.

Quindi il mio problema ora è che dovrò cambiare il progetto dall'usare il modello di stato nell'utilizzo dell'ereditarietà. Tuttavia, l'ereditarietà non consente al mio di cambiare dinamicamente il mio stato in fase di esecuzione (il problema che il diagramma di stato risolve inizialmente).

quindi le mie domande:

  1. Lo schema di stato fallisce quando un'entità in ogni stato ha attributi aggiuntivi? qual è l'alternativa?
  2. Come devo mantenere le mie entità in questo caso? Ereditarietà di una tabella? tabella per classe? tabella per classe di calcestruzzo?
  3. Se devo mantenere alcuni attributi da uno stato precedente (Rimborso di un ordine spedito, ma non eliminare lo stato di spedizione dallo stato Spedito), come ci si avvicina a questo problema?
  4. Come fai a tenere traccia dell'ordine in cui si sono verificati gli stati?
posta Songo 22.01.2014 - 11:28
fonte

1 risposta

2

No, lo schema di stato non fallisce. Basta rendere gli attributi aggiuntivi "annulla" parte dello stato "Cancellato" e gli attributi aggiuntivi "rimborsati" parte dello stato "Rimborsato" (hai appena dimenticato quest'ultimo stato nel tuo diagramma, immagino?)

Poiché ogni entità "stato" è un aggregato di SalesOrder , qualsiasi attributo di "stato" può essere visto solo come "aggiunta di dettagli" a SalesOrder .

Il tipo di mapping di eredità che scegli per la tua OrderState gerarchia in realtà non ha importanza per il tuo problema, ognuno dei tre tipici funzionerà.

Lo schema di stato consente inoltre di mantenere gli attributi di uno stato precedente anche quando lo stato cambia in seguito. Ad esempio, potrebbe essere necessario mantenere "l'indirizzo di spedizione" anche quando lo stato cambia da "Spedito" a "Fatturato". Questo può essere risolto consentendo più stati contemporaneamente, basta creare la relazione tra SalesOrder e OrderState "1: n" invece di "1: 1". Quindi non "cambia lo stato dalla spedizione alla fatturazione" ma aggiungi lo stato aggiuntivo "fatturato" a un'entità "StateOrder", senza rimuovere preventivamente lo stato "fatturato". Ovviamente, utilizzando questo modello, quando si cercano tutti gli ordini da spedire, è necessario verificare non solo gli ordini "concessi", ma "gli ordini concessi ma non già spediti". Ma questo è solo un dettaglio dell'elaborazione che non dovrebbe essere troppo difficile da gestire.

Avere più stati è IMHO il modello "migliore", poiché riflette la situazione del mondo reale più adeguata. Ad esempio, qualcosa che hai spedito e fatturato è "spedito e fatturato", non "fatturato invece di spedito".

    
risposta data 22.01.2014 - 12:57
fonte

Leggi altre domande sui tag