E aí galera, blz? Sei que que a questão de desenvolvimento em camadas já foi muito discutido aqui, mas preciso tirar umas dúvidas a respeito do desenvolvimento em camadas com Swing.
Bom em minha aplicação existe a camada de Interface(view) com JFrames, JInternalFrames e tal, em minha camada de lógica de negócios eu tenho o objeto para validação e e tenho meu DAO.
Queria saber quais são as validações que vcs fazem na camada de negócios?
Onde vcs validam, por exemplo, se um campo campo foi digitado corretamente?Se for na lógica de negócios, como vcs fazem com o focu?(dar um requestFocus() no campo que que foi digitado errado e etc).
:roll: :?:
Bom, por enquanto vou fazer “somente” estas perguntas.
[quote=“paulohbmetal”]Onde vcs validam, por exemplo, se um campo campo foi digitado corretamente?Se for na lógica de negócios, como vcs fazem com o focu?(dar um requestFocus() no campo que que foi digitado errado e etc).
[/quote]
uma forma para se fazer isso é: quando for pra validar o CONTEÚDO vc valida na lógica de negócio (na camada de Controle). Quando for pra validar a FORMA vc valida na view.
Os erros de conteúdo validados no Controle podem lançar exceções, que são capturadas na view e inclusive assim vc tem a mensagem de erro para exibir e controla o foco o que quiser daí…
Eu já tinha pensado nisso… Mas, por exemplo um formulário muito extenso, vou ter que criar uma exceção por campo validado?Por exemplo uma grid de proprieades, cada linha tem uma informação diferente e tal…Pois se eu criar uma genérica, não vou poder identificar o campo.
[quote=“paulohbmetal”]
Eu já tinha pensado nisso… Mas, por exemplo um formulário muito extenso, vou ter que criar uma exceção por campo validado?[/quote]
Você pode usar um conjunto pequeno de exceções e fazê-las trazer algum jeito de identificar o componente. Nada que rpenda sua regra de negócios à view, mas algo que a view saiba onde o erro ocorreu. Por exemplo, um ValorNaoPermitidoException com um atributo valorProblematico, que dê a dica de em qual lugar jogar teu focus.
99% você não repcisa fazer nada com uma exceção a não ser extends, mas as vezes pode ser útil…
[quote=“pcalcado”][quote=“paulohbmetal”]
Eu já tinha pensado nisso… Mas, por exemplo um formulário muito extenso, vou ter que criar uma exceção por campo validado?[/quote]
Você pode usar um conjunto pequeno de exceções e fazê-las trazer algum jeito de identificar o componente. Nada que rpenda sua regra de negócios à view, mas algo que a view saiba onde o erro ocorreu. Por exemplo, um ValorNaoPermitidoException com um atributo valorProblematico, que dê a dica de em qual lugar jogar teu focus.
99% você não repcisa fazer nada com uma exceção a não ser extends, mas as vezes pode ser útil…
[]s[/quote]
É, mas ainda fica esquisito…Mas, vc já viu/desenvolveu/tem exemplo sei lá de, alguma coisa parecida com isso?O phoda, é não prender o Business a View…E…Me parece que estou precisando de um pattern… Existem vários patterns, mas na maioria dos exemplos voltados para Web, e não tem(eu acho) esse tipo de preocupação…
O uso de swing tem enormes vantagens sobre a pobre interface html + javascript. Uma delas é a validação dos campos que pode ser feita na própria interface. Há 2 modos e os dois podem ser usados juntos, balanceando de acordo com os requisitos da interface:[list]- Validar logo no componente que lê o campo. Coisas do tipo não aceita vazio, string no lugar de data, etc.
Validar todo o form em conjunto. Neste caso é preciso usar o pattern observer/observable para antes de enviar os campos do form para o servidor se faça uma consistência completa.[/list]Não há necessidade de enviar lixo para o servidor. As exceções e os logs você joga para um arquivo no cliente e depois, um dia talvez, você faz upload deste arquivo para o servidor (identificando o cliente).
[quote=“paulohbmetal”]
É, mas ainda fica esquisito…Mas, vc já viu/desenvolveu/tem exemplo sei lá de, alguma coisa parecida com isso?O phoda, é não prender o Business a View…E…Me parece que estou precisando de um pattern… Existem vários patterns, mas na maioria dos exemplos voltados para Web, e não tem(eu acho) esse tipo de preocupação…[/quote]
Usandod este jeito, seu modleo não sabe sobre a View. Ele apenas diz que o valor X é ilegal, a view que se dane pra dar focus onde for [as camadas só se conhecem em um sentido].
O meio ‘padrão’ é passar exceções, você pode diminuir a granularidade da sua verificação, mas isso pode ser muito ruim, principalmente em ambientes distribuidos.
Mas não vejo o problema tão grande… se eu paso um bean pra minha regra de negócios e ela retorna uma ValorNaoPermitidoExceptiond a vida, ela precisa me dizer qual. Em um ambiente web eu posso, em alguns casos, pegar a msg e jogar pro usuário ver [‘CEP tem qeu ter x caracteres’, etc.], você vai ter que dar um jeito da exceção te dizer isso e você pegar no swing. Uma campo ‘nome’ é melhor de identificar que parsear uma msg da exceção…
O uso de swing tem enormes vantagens sobre a pobre interface html + javascript. Uma delas é a validação dos campos que pode ser feita na própria interface. Há 2 modos e os dois podem ser usados juntos, balanceando de acordo com os requisitos da interface:[list]- Validar logo no componente que lê o campo. Coisas do tipo não aceita vazio, string no lugar de data, etc.
Validar todo o form em conjunto. Neste caso é preciso usar o pattern observer/observable para antes de enviar os campos do form para o servidor se faça uma consistência completa.[/list]Não há necessidade de enviar lixo para o servidor. As exceções e os logs você joga para um arquivo no cliente e depois, um dia talvez, você faz upload deste arquivo para o servidor (identificando o cliente).
[]s
Luca[/quote]
Luca, vc tem um exemplo do pattern observer/observable sendo usado neste tipo de caso(Swing, focus e tal)? :roll:
Paulo, infelizmente não posso passar nada porque o que tenho faz parte de uma aplicação complexa e eu precisaria retirar tudo o que não interessa para poder ter alguma serventia como exemplo.
Na verdade tudo o que perguntou já tinha sido respondido pelo isneiqui. Eu e o Philip ficamos entrando em mais detalhes só para complementar. Agora é sua vez de por a mão na massa.
Estude os observer/observable que existem na linguagem desde o Java 1.x. O seu uso permitirá que verifique todos os componentes de uma só vez. Em caso de sucesso passe para o próximo item da cadeia de responsabilidades que provavelmente envia os dados para o servidor. Em caso de falha jogue uma caixa de mensagem listando todos os erros e volte para a tela.
Nesta última edição da MundoJava, o Peter Jandi escreveu um artigo muito legal descrevendo os principais padrões de projetos em Java, vale dar uma conferida.
Na minha opinião, todas as pessoas que precisam de uma interface gráfica desktop deveriam considerar frameworks XUL como o Thinlet antes de tomar uma decisão final.
Dependendo da aplicação, pode-se obter uma diferença de produtividade brutal (em comparação com o Swing) usando um framework como esse.
Houve uma apresentação ótima sobre o assunto no JustJava, feita pelo Michael Santos: Simplicidade, Escalabilidade,Produtividade e Testabilidade com J2EE, AOP e Rich Clients.
Existem vários patterns, mas na maioria dos exemplos voltados para Web, e não tem(eu acho) esse tipo de preocupação…
