<longo>
O problema que eu vejo � que o termo Java Beans j� se tornou pejorativo.
Qualquer componente hoje t� sendo tratado como Java Bean, pouco sendo levado
em considera��es se existe construtor p�blico default, gets/sets, se �
serializ�vel....

Tanto taglibs quando java beans s�o alternativas para a implementa��o do
design pattern View Helper. Um View Helper tem por responsabilidade ajudar
algum elemento de apresenta��o de dados (ie JSP) na recupera��o ou
formata��o das informa��es. Normalmente utilizamos taglibs para a parte de
formata��o e javabeans para a recupera��o.

Nesta linha, pensem nos javabeans n�o como componentes de neg�cio, mas sim
como gateways para um outro mundo, que pode ser EJB, ou qualquer outra
coisa. Fazendo assim, vc tem a sua camada de apresenta��o altamente acoplada
a estes javabeans que lhe abstrai toda a complexidade implementada na camada
de neg�cios. J� a camada de neg�cio, pode ser implementada com classes
normais, utilizando DAOs, facades e tal.

Outra coisa, a utiliza��o de algum framework MVC disciplina o
desenvolvimento, mas n�o faz m�gica.

MVC = Model - View - *Controller*

- Model = entidades que fazem parte do dom�nio do neg�cio e que devem ser
reutilizadas para diferentes tipos de apresenta��es. Componentes de neg�cio,
Value Objects, EJBs...

- View = represeta��o das informa��es que ser�o apresentadas ao cliente.
JSP, taglibs, HTML, FormBeans, Value Objects

- Controller = receber requisi��es do cliente, invocar opera��es de neg�cio,
controlar a sequ�ncia de telas... O framework pode implementar esta
sequ�ncia, mas a� cabe a vc entrar num outro n�vel de preocupa��o. Por
exemplo, o Struts implementa o elemento Controller numa servlet chamada
ActionServlet (e RequestProcessor) que funciona como um Front Controller +
Request Dispatcher, recebendo todas as requisi��es, e delegando para os
respectivos "componentes de neg�cio" (Helpers) respons�veis por aquela
requisi��o. Estes componentes seriam os ActionBeans, j� menciodados por
algu�m aqui na lista. Entretanto, n�o � pq s� sobrou o ActionBean pra vc
implementar que vc vai colocar toda a l�gica de neg�cio l� dentro.
Considere-o  como sendo o _seu controller_  e n�o como um helper do
controller dos outros. Fa�a o ActionBean acessar outros componentes mais
espec�ficos (Model), independentes de framework,  pra ver se aumenta essa
nossa reusabilidade.

</longo>

[]s
By Ale!

----- Original Message -----
From: "Claudio Augusto Teixeira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 25, 2002 6:23 PM
Subject: [enterprise-list] Re:[enterprise-list] Beans x Taglibs - L�gica de
Neg�cios


> Claudio, acredito que a confusao gerada seja entre logica de negocio e
logica de apresentacao.
>
> Logica de Negocio:
>
> Os fundamentos do encapsulamento dizem que um dado so pode ser setado se
estiver valido. Assim mantem a
> integridade do software e faz com que cada classe cuide dos seu proprios
dados. Logo, se vc quando cria um
> metodo set para a sua classe apenas atribui o valor passo ao membro de
dados interno realmente ele nao serve
> para nada.
>
> Agora pense pelo lado de que, um set so pode ocorrer se o dado eh valido.
Por exemplo, um setCpf, so pode
> funcionar se o cpf for valido, caso nao seja, deve ser lancada uma
CpfInvalidoException.
>
> Eh sobre isso que se referem os livros quanto a manter a logica nos beans.
>
> Logica de Apresentacao:
>
> Se refere ao comportamento de viewers e forms, que de acordo com contexto
podem se comportar de uma
> maneira totalmente diferente.  Nesse caso sao as suas taglibs, e por
experiencia vou lhe ser franco,
> dependendo do caso podem ficar extremamente complexas.
>
> Por exemplo, em uma aplicacao em que trabalhei, as opcoes de menu se
customizavao de acordo com o perfil do
> usuario, so que esse perfil esta amarrado a dezenas de regras tb
customizaveis, os codigos dos viewers ficaram
> extremamente complexos, mas todas as regras de negocio eram tratadas
dentro de beans.
>
> Resumindo, se a logica que vc esta concentrando nas taglibs eh de
apresentacao,  eh bem possivel que esteja
> correta.
>
> Espero ter ajudado,
>
> Abraco,
>
> Claudio Augusto Teixeira
> [EMAIL PROTECTED]
> Procwork Tecnologia e Treinamento
> Tels: 11 5504-0273 comercial
>       11 9657-4945 celular
>
> Site Pessoal: claudio.com.br
>
>
> --------------------------------------------------------------------------
------------------
>
>
>
>        Estou no momento fazendo uma aplica��o em que estou usando
> servlets, taglibs e javabeans. No entanto, estou vendo que pelo
> projeto da aplica��o estou tendendo muito a concentrar l�gica
> nas taglibs - a aplica��o tem telas din�micas que dependem, por
> exemplo, de dados no banco de dados.
>
>      Li no entanto que essa n�o � uma boa estrat�gia. A
> aplica��o � razoavelmente simples, estarei errado em fazer
> isso? Li que o correto seria concentrar l�gica de neg�cios
> em java beans, mas n�o vejo como os javabeans serviriam
> para isso j� que se resumem a getVar() e setVar() que
> podem ser colocados como tags em um JSP. Eu embutiria processamento
> adicional nesses set's e get's, � isso? Ou n�o?
>
>      Como seria uma aplica��o em que se concentraria
> l�gica de neg�cios nos JavaBeans?
>
>      []s,
>
>      Patola (Cl�udio Sampaio)
>
>
> [
>
>
>
> ---------------------------------------------------------------------
> Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
> Para comandos adicionais, envie mensagem para:
[EMAIL PROTECTED]
>
>



---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para: 
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]

Responder a