[quote=darkan666]drsmachado e sergiotaborda
o meu xhtml chama a classe controller… certo?
ai a controller faz todas as validações se estiver ok… chama quem?
a Dao ou a classe de Serviço (da qual eu não tenho a mínima ideia do que seja)?
nas ultimas repostas em relação a controller acessar ou não a Dao foi
divergente, não sei exatamente qual é a correta…
drsmachado esse é o problema… não sei como semapara a minha “controller” (Managed Bean)
em Managed Bean e Serviço
me desculpem o meu nível de iguinorância em relação a isso…[/quote]
Pense tomadas eletricas. Pense que cada camada tem um plug macho na chamada a ela só que cada plug é diferente. Cada um tem formatos de pinos diferentes.
O que vc precisa ?
Adaptadores.
A camada de apresentação onde está o jsf e os managed beans “termina” no managed bean. A camada a seguir (Dominio tb chamada “negocio”) começa com um service ( o DAO é um service também por isso que é possivel considerar que ele está na camada de negocio e ser acessado diretamente, mas na minha opinião é um tipo de serviço diferente é equivalente ao managed bean chamar um enviador de email, é um serviço, mas não é um serviço que ele deveria chamar).
Só que o service da camada de dominio tem pinos diferentes. Então vc precisa se um adaptador. Aqui vc tem 2 opções. Ou vc adapta a camada de apresentação a encaixar na de dominio, ou a de dominio a encaixar na de apresentação. Na primeira vc cria um objeto que existe na camada de apresentação, mas representa a camada de dominio. Este objeto é chamado pelo padrão “Business Delegate”. Na segunda vc cria um serviço que serve apenas para ser chamado da camada de apresentação. Estes são os Service Façade. Neste caso um controlador só pode chamar serviços que são service façade e nenhum outro tipo de service. Dito de outra forma, a camada de dominio só publica estes serviços. Só estes são publicos. O resto é privado e vc nem sabe como é.
O mesmo conceito é usado nas outras camadas. Entre a camada de dominio e a de integração vc pode usar um equivalente ao “business delegate” que seria o Domain Sotre ( que é o padrão do JPA e Hibernate) ou o 'façade" que seria o DAO. ( O DAO é um service façade da camada de integração)
Atualmente o padrão escolhido tende a dar mais importancia ao dominio. Isto porque é no dominio que estão as regras e as regras é que custam mais dinheiro implementar. então é dado preferencia ao Service Façade e ao DomainStore respetivamente em cada “ponta” da camda de dominio.
Uma forma de não confundir camadas com MVC é pensar em 5 camadas : Cliente ( o browser , applet ou swing dektop) , Apresentação (que dá suporte ao cliente, REST, SOAP ou frameworks action based ) , Dominio ( onde estão as entidades, os serviços, os repositorios, os validadores, etc… tudo o que tenha regra de negocio), Integração ( meio de campo com a persistencia que pode ser arquivo , banco de dados, outros sistemas etc… ) , Recursos (onde os dados estão de fato: SGDB , FileSystema, BigData, etc… ) Assim não dá para confundir com o MVC que só é usado no design na camada Cliente e na camada Apresentação.
Quando vc cria um serviço em um sistema muito simples de cadastro parece bobo porque o que ele realmente vai fazer é só delegar para o DAO. mas é assim mesmo.
O padrão só mostra o que vale em casos de uso que não são cadastros como relatorios, telas de processo, etc… ou seja, em algo que tenha realmente um processamento mais complexo do que simplesmente salvar. Contudo, mesmo num simples sabe o service irá validar os dados e só depois passar ao dao.
É que o seu exemplo é muito simples. Mas em termos de arquiteura e camadas ha que separar, não importa a complexidade real. Algumas pessoas acham bobagem simplesmente delegar - chamam isso de sobre-engenharia - mas a real é que isto é uma questão de Separação de Reponsabilidade , não temos culpa que as responsabilidade sejam simples. O que interessa é que estão separadas.
