Modelo MVC (Standalone)

Fala, Daniel…

bem, vejo as coisas da seguinte maneira:
No caso de trabalhar com padrões de projetos, não importa qual seja, o que você precisa ter em mente, é o que aquele padrão tem de bom, o que pode ter de ruim e até onde ele pode te ajudar, se ele será solução para (todo ou parte de) seu problema.
Sendo mais direto, o padrão MVC é algo pensado dessa maneira, para que você possa separar o joio do trigo (até aí, sei que você já sabe e eu não preciso te lembrar disso). Oras, se você já sabe, então você não precisa se preocupar se a SUA forma de usar o padrão irá quebrá-lo ou não. Por exemplo: cada um de nós aprendemos a somar 2+2=4, certo? Sabemos que isso é uma operação de adição.
Se você quiser apresentar a operação acima usando números de base binária, o que muda? Apenas o sistema numérico, porém, a operação em si, continua a mesma. Penso que o mesmo se aplica a padrões de projetos. E é justamente aí que a documenta tem valor fundamental, pois do mesmo jeito que uma documentação da sua operação de soma com base binária, me informa de antemão o que verei pela frente, a documentação do seu software dirá à você mesmo, inclusive, como você aplicou o MVC (ou Layers, ou Command, não importa) dentro de seu projeto!

Ajudei ou compliquei?

Entendi sim…
só queria algums opiniões pra obter uma luz ou diferentes maneiras de se implementar isso, para que possa escolher um modo legal de se fazer isso, fazendo uma coisa mais coesa e menos acoplada.

Já tá desacoplado pela Façade!!

A Fachada pode ter referências pros objetos que ela usa. Ela só serve mesmo pra desacoplar. Pensa que vc tem um SocketBroker e um RMIBroker (pensa nada, vc tem! :)).

Vc pode ter uma fachada para o envio assim:

public interface BrokerManager {

public Broker getBroker(DestinationDescriptor object);

}

Nessa interface, você não falou nada sobre quantos tipos de brokers vc tem. Você tem um DestinationDescriptor que, hoje, pode ter apenas duas implementações (uma que descreve um destino RMI, e um que descreve um destino de sockect (provavelmente um InetAddress). Mas se um dia vc suporta JXTA ou algum jeito louco de enviar objetos, vc vai criar várias classes novas (um broker, um Descriptor, factories, wrappers e utilizadores) para o seu protocolo novo e seu código velho que não tem nada a ver com elas não vai precisar ser recompilado.

C quer menos acoplamento que isso??

[]s!!

tanjajr tem razão em falar que não tem o jeito certo etc. Mais como vc esta perguntando como agente faria, bem eu colocaria o controlador como um único listener para mapear todos os eventos e decidir que classes são responsáveis por tratar isso. A fachada esta beleza mais para encapsular os lookups e chamadas rmi crie uma bussinesDelegate na frente da fachada.

Eu chutei o pau da barraca…

To implementando meio baseado no modelo MVC (2), que eu to acostumado na web. A diferença é que ele é assíncrono, com relação ao tempo de requisição e resposta. Ficou um modelo meio híbrido.

Um agente do meu servidor fica rodando e checando o estado do jogo e quando atinge certo estado ele envia mensagem ao(s) cliente(s).

O Controller fica responsável em pegar essa mensagem e encaminhar ao broker de conexões remotas e atualizar os dados na GUI.

Bom, é isso aí.

Essse é um projeto pessoal e mais como um hobby, além de ser uma ótima maneira de aprender algumas coisas. Estou pensando em publicar todo o projeto (especificação, modelos, diagramas e fontes) aqui no site do GUJ.

Abraços
Valeu o help!!!