Olá, tenho algumas dúvidas que não me deixam mais durmir… hummmmmmmmm, ok eu durmo sim vai, mais ainda tenho as dúvidsa hehe.
Seguinte, muito se fala e eu concordo plenamente sobre:
- “não utilizar get e set apenas para colocar e recuperar dados do objeto, ao invés disso tenha objetos inteligentes que manipulão seu próprio estado”;
- “comunicação entre camadas devem seguir uma hierarquia e para não “pular” camadas”;
- “DDD e o conceito de repository”.
Bem em cima disso eis minhas dúvidas que eu gostaria muito de saná-las de uma vez por todas:
1. Comunição entre camadas: Muitos projetos em que participo e participei utilizam uma estrutura mais ou menos da seguinte maneira [Visualização (com JSF por exemplo, etc), Negócio (com EJB como infraestrutura por exemplo) e Persistência (com Hibernate e JPA)]. Eis o que cada camada continha e o funcionamento.
VISUALIZAÇÃO: Aqui tinha todas as minhas paginas ou interfaces de interação com clientes;
NEGÓCIO: Ficavam meus EJBs que executavam as regras de negócio, e realizavam inclusive a persistência; [b]PERSISTÊNCIA[/b]: Nessa camada apesar do nome, não era quem realizava a persistência, apenas continham entidades e POJOS que eram utilizados como VOs apenas para trazer dados da VISUALIZACAO para o negócio efetuar ações sobre eles, geralmente classes para os telas de consulta da VISUALIZACAO encher de dados para a camada de NEGOCIO processar que eram os chamados CRITERIA de busca;
Alguns projetos fugiam dessa estrutura, porém a maioria era assim, estou muito incomodado com a forma que ela funciona, por exemplo vi alguns artigos do Shoes que são ótimos por sinal, falando que as camadas devem se comunicar com a sua camada abaixo somente e não quebrar a hierarquia de camadas, e que a lógica de negócio devem ficar nos objetos de domínio e não para servirem apenas como struct, como no C. Acredito que essa estrutura em que trabalhei nada tem de OO, e se parece muito com programação procedural.
Bem nessa estrutura que descrevi, a visualização tinha uma dependência com a camada de PERSITENCIA, por que as telas colocavam os dados direto dentro da entidade, que por sua vez eram encaminhadas para a camada de NEGÖCIO, isso forçava a inclusão de get e set nas entidades devido a exigência dos frameworks web, e nisso surgem minhas dúvidas:
- Como resolver isso? crio objetos POJOS apenas para popular na camada de VISUALIZACAO e lá no NEGOCIO eu crio meu objeto de dominio com as informações?
- Qual a solução mais inteligente para isso?
- Como tirar essa dependência da VISUALIZACAO com a PERSISTENCIA.
2. DDD e repository: Já vi e percebi a vantagens do DDD e como podemos ter objetos bem mais inteligente, encapsulados etc, mais tenho uma duvida, de como ficaria a estrutura na interação do objeto de domínio com o Repository. Até onde si o Repository fornece serviços externos ao meu objeto de domínio por exemplo, no meu objeto de domínio Usuário eu teria um repository para ele, sei lá UsuarioRepository da vida, que forneceria por exemplo metodos para consultar alguma coisa em um banco de dados ou executar alguma ação fora do objeto de domínio. Ai surge as dúvidas hehe:
- É essa a idéia que eu entendi mesmo do Repository?
- Como ficaria isso no código, seria algo como:
@Entity
public class Usuario{
@EJB
private UsuarioRepository repository;
public void save(){
//Regra de negócio entraria aqui por exemplo
repository.save(this);
}
}
- Se não for isso, como funcionaria esta idéia?
Bom acredito que a partir dessa dúvidas respondidas poderei formular outras que tenho, espero que o pessoal contribua
Obrigado
