Arquitetura de sistema Swing...

O Controlador é quem recebe toda e qualquer solicitação da visualização e repassa para o lugar correto.

Falando assim, pode pareceruma super-classe faz-tudo, mas não, o controlador apenas repassa a solicitação para outro trabalhador, é o nosso famoso 'despachante', tão comum em repartições públicas brasileiras

[]s

caiofilipini wrote:

paulohbmetal wrote:Vc tem algum exemplo de controller fazendo isso?Seria implementado por um facade?

Não exatamente.

Não tenho nenhum exemplo de controller pra aplicações desktop. Mas você pode dar uma olhada no Pendulum, que é uma implementação de MVC pra desktop baseada no XWork e no PicoContainer.

[]'s

Não, acho que vou ficar com o DAO mesmo...

Agora gostaria de ídéias para nomenclatura, já que está parecendo tão "tosca"...

A Paz!!

pcalcado wrote:O Controlador é quem recebe toda e qualquer solicitação da visualização e repassa para o lugar correto.

Falando assim, pode pareceruma super-classe faz-tudo, mas não, o controlador apenas repassa a solicitação para outro trabalhador, é o nosso famoso 'despachante', tão comum em repartições públicas brasileiras

[]s

Mas se ele somente "repassa", qual seria a real vantagem de usá-lo?

A Paz!!

paulohbmetal wrote:Não, acho que vou ficar com o DAO mesmo...

Veja bem, DAO é uma coisa, Controller é outra *completamente diferente*!

paulohbmetal wrote:Mas se ele somente "repassa", qual seria a real vantagem de usá-lo?

Tem certeza que você leu as minhas respostas? Eu falei sobre isso na minha primeira:

caiofilipini wrote:No seu caso, parece que tá faltando separar melhor as coisas, implementar alguém (controller) que intermedie as chamadas da sua view para os seus objetos de negócio. Se isso não for feito, você estará amarrando demais a sua view com os objetos de negócio, e isso pode te dar dor de cabeça, principalmente quando você precisar mudar qualquer coisa na camada de negócio.

[]'s

paulohbmetal wrote:
Mas se ele somente "repassa", qual seria a real vantagem de usá-lo?

Porque você não espalharia suas classes de negócio (sejam interfaces para elas, façades...) pela sua apresentação.

[]s

caiofilipini wrote:Veja bem, DAO é uma coisa, Controller é outra *completamente diferente*!

Putz que confusão...

Eu sei...Estou falando entre MVC e DAO.

Agora sobre o "repassa", eu estou respondendo o pcalcado.

A Paz!!

Eu falo em real vantagem, pois se for para não acoplar a Apresentação à Regra de Negócio, esta classe intermediária não estaria fazendo isso?Ou tem mais "outra coisa" que ela pode fazer antes de passar para a classe de Regra de Negócio?

A Paz!!

pcalcado wrote:

paulohbmetal wrote:
Mas se ele somente "repassa", qual seria a real vantagem de usá-lo?

Porque você não espalharia suas classes de negócio (sejam interfaces para elas, façades...) pela sua apresentação.

[]s

Hum...Então quer dizer, por exemplo, se tenho que fazer acesso a duas classes de Regra de Negócio diferentes em minha GUI, eu o faria através desta classe intermediária?É isso?

A Paz!!

paulohbmetal wrote:

caiofilipini wrote:Veja bem, DAO é uma coisa, Controller é outra *completamente diferente*!

Putz que confusão...
Eu sei...Estou falando entre MVC e DAO.

Ele quis dizer q vc pode usar DAo e MVC trsanquilamente no mesmo sistema (deveria, aliás) e que xWork, blablabla não interfere no uso de DAO ou não.

Qual classe intermediária?

Considere por exemplo a estrutura de servlets. Um formulário HTML não realiza ações (ok, num mundo perfeito...), ele as passa para servlets.

Considerando que implementar um Servlet para cada ação a ser realizada é uma prática muito ruim pela compelxidade e blablabla, você implementa o padrão Command para realizar sua ação (ok, você poderia ter MVC com servlets puros, mas vamos esquecer isso por agora).

Usando o padrão Command, você teria um objeto por ação executada (sem if(isso) faz aquilo, pelo amor de Zahl!), e o seu Command aciona as classes encessárias para efetuar sua ação.

A vantagem é que sua classe de visualização, seu formulário, sua página web, sei lá, não precisa saber qual a classe que faz a ação dela. Num modelo em HTTP, ela apenas precisa saber que para inserir um usuário ela deve passar seus parâmetros para o controlador (que, enste caso, é um servlet) passando a chave 'incluirUsuario.do (exemplo Struts, péssima prática, aliás

). O controlador sabe que esta chave indica para usar o objeto Command, por exemplo, IncluirUsuario (poderia ser um método de um objeto de granulação grossa, mas vamos manter simples), passar os parâmetros e mandar ele se virar.

Sua classe de visualização fica *muito* mais limpa e *muito* menos acoplada.

Zahl wrote:
Aumente coesão
Diminua acoplamento

[]s

This message was edited 1 time. Last update was at 12/11/2004 16:18:44

pcalcado wrote:Usando o padrão Command, você teria um objeto por ação executada (sem if(isso) faz aquilo, pelo amor de Zahl!), e o seu Command aciona as classes encessárias para efetuar sua ação.

pcalcado wrote:A vantagem é que sua classe de visualização, seu formulário, sua página web, sei lá, não precisa saber qual a classe que faz a ação dela. Num modelo em HTTP, ela apenas precisa saber que para inserir um usuário ela deve passar seus parâmetros para o controlador (que, enste caso, é um servlet) passando a chave 'incluirUsuario.do (exemplo Struts, péssima prática, aliás ). O controlador sabe que esta chave indica para usar o objeto Command, por exemplo, IncluirUsuario (poderia ser um método de um objeto de granulação grossa, mas vamos manter simples), passar os parâmetros e mandar ele se virar.

Ô lôco...

Que volta!!

Então vamos ver se eu entendi, eu teria um controlador para toda a minha aplicação e essa aplicação delegaria ao comand o que ele deve fazer passando os parâmetros nescessários e o comand delegaria a minha Regra de Negócios?Ou eu estou misturando tudo?

O problema é que não desenvolvo pra Web, e ás vezes fico meio perdido...

A Paz!!

Paulo,

Não querendo ser chato, pelo modelo que tu implementou vou quebrar teu sistema ok? Vamos pensar um pouco.
Sou o usuario que te contratou para fazer o sistema. Ai no dia da apresentacao do mesmo eu olho e digo, ué mas eu pensava que ia ser na Web o sistema. Nesse momento tu faria uma cara +- assim

.

Agora pensa o problemao que tu teria que resolver deixando como esta, não acha?
Pesando mais um pouco, se tivesse usando MVC qual seria teu problema realmente? Trocar a View nao é?

Voltando as dicas, eu procuro usar o pattern Observer na minha view para notificar as alteracoes.

This message was edited 2 times. Last update was at 16/11/2004 08:59:54

fabgp2001 wrote:
Sou o usuario que te contratou para fazer o sistema. Ai no dia da apresentacao do mesmo eu olho e digo, ué mas eu pensava que ia ser na Web o sistema. Nesse momento tu faria uma cara +- assim .

É vc tem razão, mas descobrir isso no dia da apresentação seria meu primeiro grande erro.

Mas estava dando uma estudada, e achei entre uns tutoriais que tenho impressos lá em casa, esse
da Sun que fala sobre DAO.

O que acham?

Achei meio estranho o fato de uma classe ter acesso a todos os DAO'S.Pro meu caso, é lógico.Vcs fazem assim, deixam tudo public?

A Paz!!

paulohbmetal wrote:É vc tem razão, mas descobrir isso no dia da apresentação seria meu primeiro grande erro.

Não pense isso, é normal o cara chegar com o sistema em baixo do braco e o cliente dizer que não era bem aquilo.

]['s

Ok, isso acontece, mas uma mudança tão drástica assim deveria ser prevista pelo programador, mesmo porque o cliente deveria ter visto uma prévia do sistema antes de ser entregue.

Mesmo assim, o modelo MVC oferece muito mais vantagens do que simplesmente facilidade em trocar de interface, mesmo porque esta facilidade depende bem mais de uma boa arquitetura de camadas do que o MVC em si, visto que dependendo de como se use MVC pode ficar mais acoplado do que views acessando objetos de negócio, não duvidem...

[]s

pcalcado wrote:Ok, isso acontece, mas uma mudança tão drástica assim deveria ser prevista pelo programador, mesmo porque o cliente deveria ter visto uma prévia do sistema antes de ser entregue.

Por isso mesmo que falo...Onde está a análise?!
É posso reconsiderar e usar o MVC mesmo...

Estava também olhando EJB e me parece uma boa, mas entro na velha história do "escrever mais"...Dá-lhes Deployment Descriptors...

O que acham?!

A Paz!!

Notícias, artigos e o maior fórum brasileiro sobre Java