Preciso de conselhos sobre como projetar interações entre várias partes do meu aplicativo


10

Estou tentando criar as "principais" classes de um aplicativo Rich Desktop baseado na plataforma NetBeans 7. Esse aplicativo consumirá serviços HTTP e, por meio de um "sistema push" sobre TCP, receberá mensagens.

  • Somos 3 desenvolvedores e queremos desenvolver módulos em paralelo
  • A aplicação será em camadas (dados, negócios, apresentação)
  • Usaremos o Modelo de apresentação para separar as responsabilidades
  • Alguns dados granulares (uma pessoa Bean, por exemplo) serão compartilhados por várias telas (e possivelmente exibidos em várias telas ao mesmo tempo)
  • ...

Somos capazes de desenvolver telas individuais, mas não sabemos exatamente como organizar o aplicativo inteiro e definir o conteúdo de cada módulo.

  1. Então, você tem algum conselho (um aplicativo de padrão / prática recomendada / livro / amostra) para coordenar / gerenciar interações dentro de todo o aplicativo?
  2. Algum conselho sobre como definir o conteúdo dos módulos?

Obrigado!


Pequeno exemplo para ilustrar o que eu quero criar: Um aplicativo Foo User Management

  1. Inicie o aplicativo
  2. À esquerda [explorer], temos uma lista de plataformas (a lista é armazenada em um arquivo local)
  3. No topo, temos o botão para adicionar uma nova plataforma (também disponível com o botão direito)
  4. Ao clicar duas vezes em uma plataforma, o aplicativo chama um serviço HTTP para recuperar uma lista completa de usuários. Esta lista é exibida no [editor] (em uma JTable)
  5. Um processo em segundo plano é iniciado: por meio de uma conexão TCP, recebemos mensagens
  6. É possível adicionar novo usuário graças a um botão na barra de ferramentas

Se o aplicativo for iniciado em outro PC e se o usuário estiver conectado à mesma plataforma, sua Lista de Usuários será atualizada dinamicamente (adicionar / remover / status: {offline / online}) (graças a mensagens)

No futuro, será fornecido um módulo de bate-papo.

Minha pergunta é (em outras palavras): algum conselho / melhor prática para decidir sobre o conteúdo de cada módulo? Se o PM (modelo de apresentação) é uma boa maneira de separar exibição / negócios e dados e criar telas, qual é a melhor maneira de vincular várias telas com base no PM? Imagine que desenvolvemos o módulo de bate-papo, como adicionar uma entrada "Discutir com ..." ao menu de contexto disponível com o botão direito do mouse na lista de usuários?


3
Não está claro o que você está perguntando. Que tal fornecer um pequeno exemplo para ilustrar sua pergunta?
Robert Harvey

Ótimo post de Geertjan Wielenga. Contém declarações de declarações de Tom Wheeler (membro do NetBeans Dream Team): java.dzone.com/news/how-to-split-into-modules
Destruição em

Respostas:


5

Dado o seu requisito, para começar com o material de processamento principal, você deve usar o Padrão de Comando e, posteriormente, você pode usar os padrões de Modelo para processadores de solicitação. E assim por diante. Não há nada chamado padrão mestre. Se houvesse, eles não precisariam mais de nós.

A idéia é ter um design que permita evoluir com os requisitos.

Eu começaria criando uma interface de módulo base e daria a interface a todos e alguns utilitários ao seu redor. Deixe que todos implementem seus próprios módulos com base no módulo base.


3

Eu acho que você está olhando para um padrão MVC bastante clássico, apoiado por serviços (RESTful, eu assumo). A chave será separar o (s) serviço (s) da interface do usuário. Isso não ocorre porque você está introduzindo uma interface do usuário alternativa, mas porque fornece clareza sobre qual deve ser a sua interface de serviço.

Portanto, quando você estiver pensando no getPeopleserviço, pense em como uma interface do usuário secundária (não Swing) iria interagir com o serviço. Se você tiver isso em mente, encontrará uma solução bastante flexível / dissociada.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.