Putz que confusão…:lol:
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!!
[quote=pcalcado][quote=paulohbmetal]
Mas se ele somente “repassa”, qual seria a real vantagem de usá-lo?:roll: [/quote]
Porque você não espalharia suas classes de negócio (sejam interfaces para elas, façades…) pela sua apresentação.
[]s[/quote]
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!!
Putz que confusão…:lol:
Eu sei…Estou falando entre MVC e DAO. [/quote]
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 :P). 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.
[]s
:?: :? :?:
[quote=pcalcado]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 :P). 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.
[/quote]
Ô lôco… :shock: 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?:oops:
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 :shock: .
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.
É 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!!
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
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!!
Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…
Dá pra evitar muito do trabalho com xdoclet, mas, sinceramente, não vale a pena. Fique onde está…
[]s
[quote=pcalcado]
Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…[/quote]
Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?!
Pois é, e o EJB 3.0?!Vcs acham que resolve o problema?!
A promessa é essa né?!..
A Paz!!
O problema de análise seguindo os meios tradicionais é que você perde muito tempo desenvolvendo algo que não agrega nenhum valor ao seu projeto e que pode ser jogado no lixo a qualquer mudança de humor do seu cliente.
Então, cuidado antes de abrir sua ferramentinha CASE e sair desenhando alucinadamente o sistema inteiro, usando 8 diagramas da UML e o diabo.
Sobre EJB 3.0, o mecanismo de persistência ainda é mais promessa do que realidade. Ainda me pergunto se, quando a especificação for lançanda, eu vou adotá-la ou permanecer ao lado do Hibernate para persistência 
Aliás, uma boa visão sobre este assunto é a do Tirsén: http://blogs.codehaus.org/people/tirsen/archives/000706_why_i_still_wont_do_ejb.html
[quote=paulohbmetal][quote=pcalcado]
Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer… seja lá que bizarrice inventarem…[/quote]
Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?! [/quote]
Claro que é demais, foi apenar um exemplo bobo, para ver alguns problemas que podem aparecer. Como o Philip falou mesmo com MVC teu sistema pode ficar estremamante acoplado e isso não é bom. Por isso trabalhar com padrão de projetos é o ideal, IoC, Observer, e por ai vai é importante.
Sobre analise, eu prefiro a visão do XP, não pense que a analise te afasta de todos os males, pois o mais comum é definir coisa demais que na realizadade o cliente não precisa. É aquela famosa figura do balanco.
]['s
E se tu usar Hibernate3 estara usando EJB 3.0, correto?
Segundo o Gavin na entrevista ao JF o Hib3 sera uma implementação da especificação do EJB 3.0 a qual ele é um dos menbros.
]['s
Alguns comentários:
Se você optar por uma arquitetura em 3 camadas (cliente swing, app server e DB) dificilmente conseguirá implementar um MVC que ligue a View (swing) ao Model (domínio de objetos no app server). Pelo menos não de uma forma muito produtiva.
Há cerca de um ano estou trabalhando em um sistema de grande porte que utiliza uma arquitetura assim. Levamos cerca de 6 meses só para defini-la: quais frameworks seriam usados, que EJB faria o que, como resolveriamos a persistência, etc.
O mais provável é que você implemente MVC na interface para apresentar dados dos seus objetos de domínio em formulários Swing.
Me parece também que existe uma série de questões complicadas que ainda não foram ponderadas para este caso:
-
A serialização e transporte de objetos do app server para o cliente e vice versa pode se tornar um grande problema. Quanto maior o número de relações entre os objetos pior será. Para resolver isso, terá que implementar proxies e possivelmente trabalhar com uma estrutura paralela de DTOs (Data Transport Objects). Escrevendo cada vez mais e mais código.
-
Certamente serão necessárias validações da entrada de dados no lado cliente. Os controles do swing (JTextFields, etc) provavelmente terão que ser estendidos para isso, ou você terá que criar Documents e outros modelos para eles.
-
Frameworks para desenvolver UI Swing são escassos e menos populares do que os que você encontra para Web. Prepare-se para escrever muito código!
Desenvolver interface em Swing é geralmente muito menos produtivo do que desenvolver interface Web. Você morre nos detalhes!
Ao apresentar a aplicação para o cliente ele esperará encontrar na interface uma riqueza de detalhes e facilidades de uso e interação que qualquer programador Delphi ou VB consegue fazer com meia dúzia de clicks, mas que vão te custar a alma para desenvolver em Swing.
Dependendo dos requisitos pode ser muito mais fácil usar XUL, com Thinlet ou outro qualquer.
Gabriel.
Não necessariamente. Uma estrutura bem distribuída oferece interface entre componentes de negócio e apresentação, a apresentação MVC utiliza esta interface como Model.
[]s
Você tem alguma idéia de como criar tal interface de maneira produtiva?
Imagine que você tem que desenvolver um formulário para entrada de todos os dados de uma Nota Fiscal recebida por uma indústria em um sitema ERP. Imagine que o objeto NotaFiscal tem uma coleção de itens e que para cada item desta coleção existem mais duas coleções e siga assim até totalizar uns 5 níveis de detalhamento. Imagine que esse detalhes devam ser informados no formulário e que ao final de tudo o usuário possa clicar em um botão “Salvar” que além de enviar o objeto para persistência no app server vai, através de Session Beans, gerar toda a movimentação de estoque necessária para o sistema e executar mais uns 10 processos em várias outras áreas do sistema (usando todos os detalhes informados) em decorrência da entrada dessa Nota Fiscal.
Um cenário assim não seria nenhum absurdo em um sistema de gestão integrado de uma empresa de grande porte.
Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.
Sim, arquitetura de Objetos distribuidos em camadas.
Se estamos falando de sistemas grandes e muito distribuídos, a complexidade afeta a produtividade, mas distribuir sua aplicação tem benefícios que nenhum 2-camadas tem.
‘Produtividade’ é um termo de marketing que as pessoas cismam em usar tecnicamente. Delphi ‘é mais produtivo’ que Java. VB também. Que tal?
É besteira querer os benefícios sem pagar o preço, e o preço de um bom design é gastar algum tempo…bem, fazendo o design!
Você precisa definir melhor suas interfaces, resposabilidades e camadas.
Dependendo do nível de distribuição e complexidade, você irá usar objetos DTO para passar dados agrupados, isso é uma limitação terrível de arquiteturas distribuídas, mas não é impossível de lidar.
Pelo seu escopo, eu acho que você está fazendo sua aplicação (de exemplo) cliente trabalhar demais, e fazer operações em lote, para depois enviar o resultado. O tempo do batch já passou, e você conseguirá problemas terríveis de acesso concorrente e transacionamento desta forma.
Se estamos falando de componentes distribuídos, aconselho uma leitura sobre o tema. Objetos internos à componentes não devem passear pelo sistema.
Em telecomunicações, geralemnte você possui mais de 3 tipos de interface para um sistema. A lógica de negócios é uma, o que varia é a interface.
Um modelo MVC utiliza as mesmas interfaces de negócio que um protocolo binário de tempo real. Para o modelo MVC, apenas estas interfaces são o modelo, para os outros clientes geralmente é um subsistema a ser acessado.
[quote=gcobr]
Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.[/quote]
Codificar isso num formulário é se manter na década de 90 para sempre. A arquitetura cliente/servidor é defasada, e mesmo essa arquitetura é má utilizada quando formulários executam regras de negócio, existem alternativas ainda dentro deste paradigma.
Olá
MVC do jeito que vc fala no Java só existe no Swing e mesmo assim parcialmente. O modelo dos frameworks web (mesmo JSF) V-C-M e V não deve dialogar diretamente com M.
OK, vide obs. acima
Nem sempre é preciso serializar os objetos. Concordo que é bem prático em termos de programação mas se o objetivo for performance é melhor dedicar um pouco mais de tempo no desenvolvimento e facilitar o uso na produção.
Certo, tudo deve ser componentizado, padronizado, pasteurizado, flavorizado, customizado, colorizado e dará muito trabalho.
O cliente resolveu usar Linux e nós já estamos prontos para tal. Vide Droga Raia, Banco Postal, etc.
[]s
Luca