A função MVP / MVC do Modelo (não anêmica) entra em conflito com a função de apresentador / controlador (responsabilidades no lugar certo, Modelo OU Apresentador)?

5

Problema?

Eu tenho visto a implementação e o processo do MVP para projetar um bom modelo de domínio ( não anêmico ). Ele diz que o modelo de domínio deve ter seu próprio comportamento e não ser um modelo de dados simples (como o DTO).

No meu caso (meu aplicativo), verifica-se que a arquitetura dos controladores está seguindo a arquitetura do modelo (modelo de jogador, controlador de jogador, modelo de jogo, controlador de jogo, ...). Então eu acho que meu modelo é anêmico porque meus objetos de modelo não contém referências a outros modelos objets, eles definem muitos métodos de acessadores (get & set) e finalmente seus métodos principais apenas modificam suas próprias propriedades de objetos.

Como faço para integrar um modelo que lida com a lógica de negócios na arquitetura MVP? E quem deve gerenciar que tipo de ação? A arquitetura do apresentador deve seguir a arquitetura do modelo? Um apresentador só deve ter acesso a uma parte do modelo ou a todos eles? O apresentador tem que ouvir a modificação do modelo e reagir de acordo? Qualquer recurso concreto na rede com exemplos?

Solução?

Crie um modelo estruturado com herança e comportamento. Vincular objetos de modelo relacionados (como coleções, propriedade de outro objeto de modelo, ...). Finalmente, ouça a modificação de eventos do modelo em controladores para enviar solicitações para a rede.

Mas, nesse caso, o papel do controlador é muito pequeno, porque o modelo manipula quase todas as modificações em si. Não é melhor "achatar" a hierarquia do modelo, para que eles não sejam dependentes entre si?

Estou confuso.

Aqui está um exemplo da minha arquitetura de aplicativos atual

Nos seguintes casos, acho que o modelo é anêmico.

Contexto: No aplicativo de jogo multijogador pela rede. Vamos dizer que temos dois jogadores com uma certa quantidade de bolas que eles têm que jogar em um barril (os jogadores têm seu próprio cano cada). É um jogo baseado em turnos.

Assim, o modelo de domínio seria (as propriedades não são digitadas):

  • Jogo (playerTurn)
  • Jogador (nome, pontuação, número de bolas jogadas)
  • Bola (cor, peso)
  • Barrel (distância, pontos, lista de bolas lançadas)

Na representação do MVP, eu criaria três apresentadores:

  • GameController
  • PlayerController
  • BarrelController

Exemplo de uso

Caso de uso n ° 1: O jogador (real) lança uma bola

Emresumo,ojogadorlançaumabola.OeventoéenviadoparaoGameController,quevalidaaaçãonaredeerespondedevoltaaodelegaroeventoparacadacontroladorespecífico.

códigoparagerar(emodificar)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()

Casodeuson°2:Abolalançadacainocano

Mesmo principe, a ação é enviada para validação (e executa uma ação relacionada potencial nos controladores pai). Finalmente, o barrel é atualizado pelo BarrelController (adicionar bola) e o modelo do jogador é atualizado pelo PlayerController (atualização de pontuação).

código para gerar (e modificar) 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()
    
por gosp 12.09.2015 / 03:09
fonte

1 resposta

1

Você está procurando por Design dirigido por domínio .

Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.

Isso é o oposto do Modelo de Domínio Anêmico.

Confira Criando modelos de domínio ruins para um exemplo mais prático.

    
por 12.09.2015 / 15:07
fonte