Ol�, Felipe, a coisa � um pouco mais complexa, em minha opini�o.
A camada de apresenta��o deve ser respons�vel pela formatacao ao seu usu�rio. Lembre-se que o usu�rio pode ser uma pessoa, um outro sistema ou qualquer outra coisa. Para mim, uma data no formato dd/mm/AAAA est� perfeito, mas para um americano n�o est�. Um subsistema pode requerer a data em um formato como ISO, n�o muito leg�vel. Mesmo que seu sistema tenha apenas um tipo de usu�rio, n�o faz parte da responsabildiade das classes de neg�cio prover apresenta��o. Isso � feito pela apresenta��o do sistema, sua interface com seus usu�rios. A quest�o das responsabilidades � definitiva no desenvolvimento de um sistema de objetos. Misturar responsabilidades de camadas � contra a pr�pria t�cnica de camadas, prov� acoplamento fora do controle e geralmente resulta num belo prato de macarr�o. Um objeto pode e deve ter mecanismos para validar sua entrada, tendo certeza que ela obedece ao contrato que seu m�todo publica. Isso � chamado asser��o. Transferir dados vindo de um formul�rio m� persist�ncia indica que falta alguma coisa. Cad� o objeto? A pr�tica de criar um pseudo-objeto (algo parecido com um registro/struct ou um bean) que apenas agrupa dados em um formul�rio tem sua utilidade na camada de apresenta��o. Como a camada de apresenta��o n�o conversa com a camada de persist�ncia, ela deve passar pela camada de dom�nio, onde beans n�o s�o bem vindos. Nessa camada, os dados enviados no formul�rio devem ser transformados em objetos de dom�nio, com comportamento, responsabilidades e estado bem definidos. Estes s�o os objetos que devem ser persistidos. []s On Wed, 23 Feb 2005 11:23:06 -0300, Felipe Vieira Silva <[EMAIL PROTECTED]> wrote: > isto � pol�mico... > > obedecer padr�es � excelente, mas �s vezes o uso de padr�es causa uma > prolifera��o de classes auxiliares e min�sculas que s� existem nos > projetos para preservar os padr�es... Neste caso, a contribui��o do > uso de padr�es neste ponto do projeto contraria o senso comum e, > portanto, fica estranho... > > Um exemplo t�pico � o struts usar ActionForm e Bean separados.. . > somente para manter "o conceito" das classes separadas em camadas. > > Um bean poderia ter o m�todo de valida��o e ser usado para transferir > os valores do formul�rio at� a camada de consist�ncia. Isso iria > contrariar o discurso dos padr�es, mas daria mais simplicidade ao > sistema ao aliminar o fr�gil processo de copiar os valores do > FormAction para o Bean com o BeanUtils... > > mas � coisa a ser discutida.... > -- Phillip Cal�ado ICQ: 1110nine38six5 M$N: [EMAIL PROTECTED] http://www.jablo.com.br/blogs/page/pcalcado http://www.jroller.com/page/pcalcado Crux Sacra Sit Mihi Lux ------------------------------------------------------------------------------------------- Ceara' Java User Group Para cancelar sua assinatura, envie um e-mail para: [EMAIL PROTECTED] Para mais informacoes, mande um e-mail para: [EMAIL PROTECTED] Falar com o administrador? e-mail para: [EMAIL PROTECTED]
