Dúvidas - Camadas

Programação Arquitetura
#1

Pessoal estou começando a ler o livro EJB 3 em ação, no capitulo 1 (pag 8-9)- ele fala do desenvolvimento em 4 camadas - que é o desenvolvimento mais comum, eu particularmente sigo este, que seria

No livro sita assim
Camada de apresentação
Camada de negocio
Camada de persistencia
Camada de banco de dados

Minha primeira dúvida, no livro é sitado as camadas acima porem ele não fala como agrupar está divisão.
Eu faço desta forma sem EJB:

Camada de apresentação
cliente.xhtml
Camada de negocio
ClienteMB(ManagendBean)
ClienteBO(seria um classe que contem gravar,editar,deletar etc e tem um clienteDAO dentro dela)
Camada de persistencia
Cliente(Entidade)
ClienteDAO
Camada de banco de dados
Oracle

Minha dúvida, managendBean fica na camada de negócio ou apresentação?

Segunda dúvida, na pagina 9 tem um paragrafo assim

"A arquitetura trandicional de quadro camadas não é perfeita. Um dos pontos mais desfavoráveis é que ela enfraquece a modelagem OO, ideal do domínio do negócio, como objeto que encapsulam tanto os dados como o comportamento.Como a arquitetura trandicional se concentra na modelagem dos processos de negócio, ao inves do domínio, a camada de negócios, tende a parecer mais como uma aplicação procedural dirigida por banco de dados do que uma OO.Como os componetes de camadas de persistencia são simples portadores de dados, eles parecem muito mais com as definiçoes de registro de banco do que com um cidadãos da primeira classe do mundo OO "

Minha dúvido, Como entender este parágrafo,

Vou escrever como eu intendo depois vocês analisam se esta certo ou erro,

Ao meu ver a arquitetura padrão de 4 camadas, deixam muito OO de lado, porque em OO é fixado a coesão e acomplamento baixo como ponto forte, ou seja uma classe deve ser objetiva e não depender da outra
Ex: Temos a entidade Cliente que tem todos os atributos ou seja o que “relamente é um cliente” está classe deveria fazer tudo que um cliente faz, como por exemplo o médoto validaCPF, na minha arquitetura de 4 camadas este metodo fica na classe ClienteBO(que contem a logica de negocio, como gravar apagar etc), e não na Cliente, isto quebra o OO certo?
Outra coisa gravar, deletar, apagar tambem não deveria ficar no Cliente ?

Obrigado

#2

1 - Tem gente que coloca no controle, tem gente que coloca na apresentacao. Mas eu nao sou muito a favor de deixar na apresentacao.
Enfim, acho que a maioria deixa no controle mesmo.

2 - Compreendi esse paragrafo da mesma forma que voce. Quanto a deletar, atualizar e afins, acho que é a unica parte que discordo. Acho que deve haver, mesmo usando OO da forma “correta”, um objeto para fazer isso, já que um cliente não pode se deletar ou atualizar. Outro objeto deve fazer isso pra ele. Depende tambem muito da forma como voce enxerga as coisas tambem, como tudo em OO. Usando do bom senso acho que nao deve fazer muita diferença xD

Só outra coisa, dentro dessa tua camada de persistencia é adequado ter tambem um ClienteDTO. Isso ajuda até a explicar melhor esse paragrafo que voce postou, pq separa ainda mais as coisas, ja que os objetos DTO tem apenas os atributos.

#3

Na verdade no JSF o controle não é o ManangedBean, no JSF o controle é o FacesServlet como cidado neste Tutorial da IBM http://www.ibm.com/developerworks/web/library/wa-dsgnpatjsf.html , mais isso ja entra em MVC, aonde eu intendo que o MVC fica na camada de apresentação,

Pra mim ainda acho que MB fica na regra de negócio.

Concordo.

Esqueci de acrescentar minhas entidades na camada de persistencia. Que seria a classe Cliente, pra mim esta classe que deveria ter o método validaCliente, mais ai ela ia para camada de negócio?

#4

Eu poria na camada de “Controller”.

#5

E como citado acima, o Cliente eu faria algo como ClienteDTO ou ClienteVO.

#6

O controller fica na camada de apresentação, porem no JSF o managendBean não seria o controle segundo o tutorial da IBM

#7

Achei esse post, parece bacana: http://www.guj.com.br/java/224363--conceitual--quem-es-tu-managed-bean-no-mvc-

Já fiz um projeto que usei o ManagedBean como Model, mas não acho elegante o ideal seria ter algo como ObejtoBO…

#8

http://www.guj.com.br/java/121363-funcao-dos-managed-beans-do-jsf

#9

Eu ainda concordo com o tutorial da IBM rsr até que me provem ao contrario…

Pessoal… deixem suas opnioes ai…

#10

Se for um DTO evite colocar metodo dentro dele, alem dos gets/sets; MAS uma boa pratica, ja que voce vai apenas VALIDAR os dados, seria usar os próprios sets para isso…Caso dê algum erro voce pode retornar uma excessao no proprio set. O DTO fica no modelo, apesar de nao fazer tanta diferença ja que vai ter import dele em todos os pacotes…A diferença fica mesmo só na organizacao na hora de voce achar uma classe pra alterar.

ManangedBean nao sao objetos que tratam eventos? Entao assim…no proprio MVC tem gente que coloca tratamento de eventos na apresentacao e tem gente que coloca no controle. Nao sou a favor de tratamento de eventos na apresentacao porque se eu quero por exemplo que após um usuario realizar uma acao o aplicativo tenha outro comportamento, ou seja diferente do que eu havia pensado antes, é mais lógico eu ir no controle para fazer essas modificacoes, e nao na apresentacao que tem a responsabilidade apenas de exibir os dados. E convenhamos que muitas vezes a gente coloca algumas regras de negocio dentro dos eventos…É irresistivel por dar menos trabalho as vezes =D

#11

Minha entidade não é DTO, eu uso ela no ManagendBean ligado ao xhtml. para popular os dados e passar como parametro no metodo gravar, não sei se ela encaixaria como um DTO
Suponhamos que não seja. ter metodos do tipo (Ex: uma classe(entidade) Faturamento ter metodos de negocio nela como faturar, fazerPedido, etc. se torna um classe da camada de negocio certo(mesmo sendo mapeada com jpa(enditade))?2)

defina o que seria evento pra vc? da um exemplo…pra mim um ManangedBean trata Lógica de negocio. como gravar, editar, etc… assim se enquadra como parte da camada de negócio… .xhtml(apresentação) envia dados — FacesServlet(controle) pega os dados envia para o ManagendBean ---- MB(Modelo) faz a regra de negócio necessaria junto com algum objeto BO.

#12

Cara, já começou errado… Quando você fala Managed Bean quer dizer Backing Bean, ou seja, o Bean que está associado a componentes de interface gráfica e é responsável por traduzir eventos do cliente para eventos do lado do servidor. Obviamente, esses Beans são parte da camada de apresentação pois se você trocar JSF por Struts vai joga-los fora e criar Actions, Forms, etc…

#13

Bem, como eu falei antes acho mais adequado colocar tratamento de eventos no controle. E ja vi muito projeto que é feito assim. Nao que seja errado colocar na apresentacao…tem gente que prefere colocar na apresentacao e tem argumentos para isso. Entao fica muito do gosto e do projeto =D

Eventos são as ações do usuario sobre a GUI como clicar num botao ou editar um grid. Basicamente eu entendo assim.

#14

Porque Backing Bean? se no Próprio JSF ele trata como Managed Bean.
Verdade, ele esta na camada de apresentação.

#15

http://download.oracle.com/javaee/5/tutorial/doc/bnapl.html#bnaqb

#16

Bem, como eu falei antes acho mais adequado colocar tratamento de eventos no controle. E ja vi muito projeto que é feito assim. Nao que seja errado colocar na apresentacao…tem gente que prefere colocar na apresentacao e tem argumentos para isso. Entao fica muito do gosto e do projeto =D

[/quote]

Não tem nada a ver com gosto. Quer a gente goste ou não, Backing Beans são parte da camada de apresentação. Se você trocar JSF por Struts ou Swing, Backing Beans deixam de existir. LOGO, eles são parte da camada de apresentação.

#17

Backing Bean se vc tiver algum componente UIInputText associado ao .xhtml
ManagendBean quando não tem nada deste tipo associado

iae?certo ou errado isto

#18

Entao dê uma olhada em MVC e veja onde geralmente colocam o tratamento de eventos. Nao estou nem entrando no merito de JSF…Estou só falando do basico de padrao de projetos. E como eu disse, tem gente que prefere colocar na apresentacao. Entao pode sim ser uma questao de gosto e, ao contrario do que voce diz, é mais comum estar no controle.

Vou até dar um exemplo bobo:

Voce tem um textfield que espera receber uma data e depois do usuario digitar essa data e pressionar enter voce faz alguma coisa. Mas antes de tudo voce vai verificar se essa data é valida - como eu disse é um exemplo bobo, existem componentes mais adequados para fazer isso - Voce acha normal verificar se essa data é valida para a realidade da sua aplicação (nao estou falando da data valida para o calendario e sim para a SUA aplicacao) dentro da apresentacao? Nao muito, entao voce pode criar um metodo no controle que verifica essa data e chamar esse metodo dentro da apresentacao. Mas em vez de voce ficar chamando metodos de outra classe desse jeito, nao seria mais logico simplesmente colocar o tratamento de eventos dentro do controle? Estou so dando um exemplo bobo, mas sabemos que existem muitos outros casos que parte das regras de negocio sao verificadas dentro dos eventos.

#19

[quote=erickfm8]Backing Bean se vc tiver algum componente UIInputText associado ao .xhtml
ManagendBean quando não tem nada deste tipo associado

iae?certo ou errado isto[/quote]

Certíssimo! É uma questão de responsabilidades: Backing Beans servem de suporte (backing) a componentes de UI, gerenciando seus estados e traduzindo eventos de UI para eventos da camda de aplicação.

#20

Entao dê uma olhada em MVC e veja onde geralmente colocam o tratamento de eventos. Nao estou nem entrando no merito de JSF…Estou só falando do basico de padrao de projetos. E como eu disse, tem gente que prefere colocar na apresentacao. Entao pode sim ser uma questao de gosto e, ao contrario do que voce diz, é mais comum estar no controle.

Vou até dar um exemplo bobo:

Voce tem um textfield que espera receber uma data e depois do usuario digitar essa data e pressionar enter voce faz alguma coisa. Mas antes de tudo voce vai verificar se essa data é valida - como eu disse é um exemplo bobo, existem componentes mais adequados para fazer isso - Voce acha normal verificar se essa data é valida para a realidade da sua aplicação (nao estou falando da data valida para o calendario e sim para a SUA aplicacao) dentro da apresentacao? Nao muito, entao voce pode criar um metodo no controle que verifica essa data e chamar esse metodo dentro da apresentacao. Mas em vez de voce ficar chamando metodos de outra classe desse jeito, nao seria mais logico simplesmente colocar o tratamento de eventos dentro do controle? Estou so dando um exemplo bobo, mas sabemos que existem muitos outros casos que parte das regras de negocio sao verificadas dentro dos eventos.[/quote]

Carlos,

não vamos confundir Model-View-Controller com divisão em Camadas… O componente View de MVC não é a camada de apresentação. Se você ler o paper original de 1979 que descreve o MVC, vai notar que a palavra camada nem existe nele. Da mesma forma na descrição no POSA1 (Pattern-Oriented Software Architecture Vol. 1).

Baseado nisso, o pattern MVC, na minha opinião, não descreve uma arquitetura em camadas, mas sim uma distribuição de papéis dentro de uma mesma camada.