Progettazione basata sul dominio - L'entità è aggiornabile in determinate circostanze

3

Ecco la mia regola aziendale:

Anyone (anonymous users) can make an Application (as in to apply for something). Applications can be updated until they are reviewed and approved by an officer. Approved applications cannot be updated.

Pertanto ho creato una classe astratta

abstract class Application {
    //various fields of application form
    //fields do not have setters, but they have getters

    public enum State {APPROVED, UNAPPROVED};

    public abstract State getState();
}

E poiché un'applicazione può essere in due stati, li ho modellati come:

public class ApprovedApplication extends Application{
    //an approved application can only be created from an unapproved application
    public ApprovedApplication(UnapprovedApplication ua) {
        //create it
    }

    public State getState() {
        State.APPROVED;
    }
}

e

public class UnapprovedApplication extends Application{     
    //only unapproved applications can be updated
    public void update(ApplicationDTO applicationDTO) {
        //do the updating
    }

    public State getState() {
        State.UNAPPROVED;
    }       
}

Sono sulla strada giusta qui o è questa spazzatura completa? E che dire dell'ufficiale che approva l'applicazione? Stai un po 'perso qui.

UnapprovedApplication.approve(Officer o); 

o

Officer.approve(UnapprovedApplication ua); ?
    
posta Reek 24.12.2015 - 23:32
fonte

2 risposte

5

Am I on the right track here or is this complete garbage?

Dopo l'approvazione di un'applicazione, la natura o il contenuto della domanda cambiano?

Se la natura dell'applicazione cambia, (significa che puoi fare cose molto diverse con esso una volta che è stata approvata), allora potresti essere sulla strada giusta, anche se sarà ancora difficile da implementare, perché lo farai ancora bisogno di creare un nuovo oggetto applicazione, (poiché ora dovrà essere di una classe diversa,) copiare il contenuto dell'oggetto vecchio (non ancora approvato) a quello nuovo e aggiornare eventuali riferimenti già esistenti in tutto il tuo sistema, che si riferiva al vecchio oggetto, per fare ora riferimento al nuovo oggetto. È un sacco di lavoro da fare, quindi è meglio avere delle buone ragioni per farlo.

Se la natura dell'applicazione non cambia in base all'approvazione, quindi, modellare semplicemente lo stato di un oggetto introducendo una nuova sottoclasse è, temo, usare le tue parole, completare la spazzatura.

Dato che hai già creato un'enum che descrive lo stato dell'applicazione, penserei che dovresti mantenere solo una classe e cambiare semplicemente il suo stato da non ancora approvata ad approvata, e un oggetto applicativo approvato sarà impedendo che il suo contenuto venga alterato. Quindi,% g_de% getter restituirà il valore di qualche campo getState() .

And what about Officer approving the application?

(Beh, che dire di loro?)

    
risposta data 24.12.2015 - 23:45
fonte
-1

Se sto capendo correttamente, un'applicazione non approvata è lo stato di default, il che significa che Application o UnapprovedApplication è ridondante (rimuovi uno).

Se ti blocchi in un angolo perché la logica di business è legata direttamente alla tua entità, diventerà davvero brutta. Di solito facciamo la logica aziendale in un livello di servizio che vive al di fuori dell'entità.

Nel tuo livello di servizio avresti il metodo approve che a sua volta costruirà il tuo oggetto stato e lo imposterà sull'entità.

Ricorda che un'entità deve corrispondere strettamente ai tuoi dati persistenti (pensa solo a getter e setter)

In che modo la transizione tra gli stati è soggettiva (logica aziendale) e dovrebbe idealmente essere fatta sempre al di fuori della tua entità

    
risposta data 28.12.2015 - 19:13
fonte

Leggi altre domande sui tag