Boa tarde pessoal,
Tenho um projeto desktop e gostaria de separar a lógica de interação (listeners) da tela de criação da interface Swing. Alguém conhece algum padrão para resolver essa questão para me indicar?
Obrigado !
MVC é a resposta. Muitas pessoas pensam hoje que MVC é algo voltado somente para o desenvolvimento web, mas isso não é verdade. Inclusive, MVC nasceu para desktop e depois foi ‘portado’ pra web. Na verdade, eu nem diria portado. Ele é um padrão que existe independente de ser uma aplicação desktop ou web. O interessante para você é observar as letrinhas mágicas ‘VC’, ou seja, view e controller. View é visualização e controller é controle. Tá. Parace óbvio, mas às vezes não é e as pessoas costumam se confundir. Vamos ver como vc poderia aplicar isso na prática, na sua aplicação desktop. Vamos usar como exemplo uma tela simples que lista alguns registros do banco de dados, por exemplo da tabela ‘CLIENTE’. Nesse caso, imagine que existe um menu na sua aplicação com uma opção ‘Cadastro de clientes’. Quando usuário clica nesse menu, a tela de listagem de clientes é exibida. Esse é o comportamento que usuário percebe. Mas como implementar isso para seguir o padrão MVC? Simplificando, vc teria ai duas classes envolvidas, uma seria ClienteController e outra ClienteList. ClienteController é uma classe ‘normal’, ou seja, ela não herda nenhum componente Swing, SWT ou coisa parecida. ClienteList seria uma ‘tela’, isto é, uma classe que poderia herdar um JFrame da vida, porque é ela que será apresentada para o usuário. Então quem faz o que? Quando o usuário clica em ‘Cadastro de clientes’, você na verdade cria um ClienteController. Esse cara é quem conhece o ‘M’ do MVC, então ele chama um ‘serviço’ da camada de negócios e obtém uma lista de clientes. É nessa hora que o controller pode fazer algum tipo de verificação de permissões de acesso ou coisa parecida. Depois que o controller obtém aquilo que precisa, ele cria ClienteList e o mostra na tela. ClienteList não conhece ‘ninguém’, ele apenas recebe os dados mastigados e os exibe dentro de uma tabela. Os listeneres que irão capturar os eventos na tela, ou seja, alguma ação do usuário estão dentro do ClienteList, porque é lá que acontecem os eventos. Se você quiser separar os listeners em uma classe à parte, para ficar mais organizado o código, tudo bem, crie um ClienteListEventListener e coloque todos os listeners nele. Quando usuário executa alguma ação, você envia essa ação para ser processada no ClienteController, jamais permitindo que o processamento seja feito a partir do ClienteList, assim você centraliza esse processamento no controller, que é o correto, em vez de espalhar tudo em várias classes e depois sofrer para dar manutenção. Assim você sabe que se houver algum erro no processamento, esse erro estará no controller. Se houver algum bug de interface, esse bug está na view, etc. Mesma coisa ocorre com a edição de registros. Você edita os registros em um ClienteEdit, mas processa isso dentro do ClienteController. Assim você usa o mesmo controller para duas views (ClienteList e ClienteEdit). Se você tiver telas bem complexas e achar que o seu controller ficou muito cheio de coisas, ai você pode ter um controller para cada view, ClienteListController e ClienteEditController. Eu trabalho exatamente dessa forma, para cadastros simples uso um controller para tudo, em operações complexas divido para ficar mais fácil de dar manutenção. Espero ter ajudado.
Obrigado Bosnic, sua explicação foi de grande importância!
Hj andei observando um framework que facilita o MVC para desktop. Procura no google code por ‘Diana framework’
ps.: Não testei.
tenho duvida quanto a isso, a view cria ClienteController ? e depois a controller cria outra view ?! Oo
afinal quem detem quem na hora de inicializar a aplicação quem inicia quem ? Controller-> view ou view->Controller?