o objeto existe, mas pode ser apenas um Bean... por qu� o struts precisa de dois objetos que tem os mesmos atributos, refletem a mesma tabela no banco e que est�o separados apenas para o qu� mesmo ?
On Wed, 23 Feb 2005 12:05:42 -0300, Phillip Cal�ado <[EMAIL PROTECTED]> wrote: > 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] > > ------------------------------------------------------------------------------------------- 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]
