problema?

Ho esaminato l'implementazione e il processo MVP per progettare un buon modello di dominio ( non anemico ). Dice che il modello di dominio dovrebbe avere il proprio comportamento e non essere un semplice modello di dati (come DTO).

Nel mio caso (la mia applicazione), si scopre che l'architettura dei controllori sta seguendo l'architettura del modello (modello del giocatore, controller del giocatore, modello di gioco, controller di gioco, ...). Quindi penso che il mio modello sia anemico perché gli oggetti del mio modello non contengono riferimenti ad altri oggetti, definiscono molti metodi di accesso (get & set) e infine i loro metodi principali modificano solo le loro proprietà dell'oggetto.

Come posso integrare una logica aziendale di gestione del modello nell'architettura MVP? E chi dovrebbe gestire quale tipo di azione? L'architettura del presentatore deve seguire l'architettura del modello? Un relatore dovrebbe avere accesso solo a una parte del modello oa tutti loro? Il presentatore deve ascoltare la modifica del modello e reagire di conseguenza? Qualsiasi risorsa concreta in rete con esempi?

Soluzione?

Crea un modello strutturato con ereditarietà e comportamento. Collega oggetti modello correlati (come collezioni, proprietà di un altro oggetto modello, ...). Infine ascolta la modifica degli eventi del modello in controller per l'invio di richieste alla rete.

Ma, in quel caso, il ruolo del controller è molto piccolo, perché il modello gestisce quasi tutte le modifiche stesse. Non è meglio "appiattire" la gerarchia del modello, in modo che non dipendano l'uno dall'altro?

Sono confuso.

Ecco un esempio della mia attuale architettura dell'app

Nei seguenti casi, penso che il modello sia anemico.

Contesto: in un'applicazione di gioco multiplayer su rete. Diciamo che abbiamo due giocatori con una certa quantità di palle che devono gettare in un barile (i giocatori hanno il loro barile ciascuno). È un gioco a turni.

Quindi il modello di dominio sarebbe (le proprietà non sono state digitate):

• Gioco (playerTurn)
• Giocatore (nome, punteggio, numero di palle lanciate)
• Sfera (colore, peso)
• Barile (distanza, punti, elenco di palle gettate dentro)

Nella rappresentazione MVP creerei tre Presentatori:

• GameController
• PlayerController
• BarrelController

Esempio di utilizzo

Caso d'uso n ° 1: Il giocatore (quello vero) lancia una palla

Nelriprendere,ilgiocatorelanciaunapalla.L'eventovieneinviatoaGameControllercheconvalidal'azionesullareteerispondeindietrodelegandol'eventoaciascuncontrollerspecifico.

codicepergenerare(emodificare)diagramm()

View->PlayerController:onThrowBall()PlayerController->GameController:onPlayerThrowsBall()GameController->GameModel:isTurn()GameModel-->GameController:trueGameController->Network:onPlayerThrowsBall()Network-->GameController:trueGameController->GameModel:updateTurn(player)GameController->PlayerController:throwBall()PlayerController->PlayerModel:updateBallThrownCount()PlayerController->View:update()

Casod'uson°2:lapallalanciatacadenelbarile

Lo stesso principio, l'azione viene inviata per la convalida (ed esegue potenziali azioni correlate nei controllori genitori). Infine, BarrelController aggiorna BarrelController (aggiungi palla) e il modello del giocatore viene aggiornato da PlayerController (punteggio di aggiornamento).

codice per generare (e modificare) diagramm ()

View -> BarrelController : onBallFallIntoBarrel()
BarrelController -> PlayerController : onBallFallIntoBarrel()
PlayerController -> GameController : onBallFallIntoBarrel()
GameController -> GameModel : isTurn()
GameModel --> GameController : true
GameController -> Network : onPlayerThrowsBallIntoBarrel()
Network --> GameController : true
GameController -> GameModel : updateTurn()
GameController -> PlayerController : throwBallIntoBarrel()
PlayerController -> BarrelController : throwBallIntoBarrel()
BarrelController -> BarrelModel : addBall()
PlayerController -> PlayerModel : updateScore()
PlayerController -> View : update()