Galera… eu fico lendo aqui os posts do pessoal e acabo me confundindo com alguns assuntos:
Vamos imaginar a seguinte arquitetura:
ServletControlador -----> Commands -----> ( BO,VO) BO -----> DAO etc…
Sempre tenho lido para esquecer dos BO’s e VO’s, então supondo que temos um sistema de cadastro de usuarios…, ao inves te ter varios objetos como os BO’s e VO’s, eu teria uma classe Usuario e essa mesma classe trataria tudo inerente a ela… dae li alguns posts sobre repositorio…e que o conceito de repositorio é algo do dominio do problema, algo que o cliente pode tratar sem ficar preso a terminologia…, Uma pergunta sobre o Usuario, ele mesmo teria os metodos cadasTraUsuario, excluiUsuario etc?? E o papel desse command, é ele que faria as validações dos dados e passaria os dados para o Usuario? Ou o command não teria essa atribuição??
Como deixar essa arquitetura mais OO? Acho que estou confundindo alguns conceitos… dae queria um esclarecimentos sobre eles!
Abraço!!
Amigão, sua mensagem ficou um pouco embolada mas vamos tentar ajudar …
Command é um Design Pattern muito usado em Web Action Frameworks, que implementam outro Design Pattern, o MVC (Na maioria dos casos somente um Front Controller). o Command é utilizado para tratar a solicitação do usuário. Geralmente utilizamos bilbiotecas de validação que vem no próprio Action Framework ou então frameworks externos como por exemplo o Hibernate Validator.
Quanto aos métodos de cadastro eles provavelmente estarão no Repository que você mencionou. Esses podem ser chamados pelo Command ou dependendo da sua arquitetura, serão chamados dentro de sua Service Layer.
Pra completar, BO e VO foram padrões criados para contornar o problema da Arquitetura EJB 1.x e 2.x. Inclusive VO hoje em dia é outro padrão e o antigo se tornou TO/DTO.
É… eu sei que ficou um pouco embolada a mensagem… mas então encima do cadastro de usuários com as operações basicas e tal… utilizando o FrontoController como tu mencionou, como ficaria as classes do sistema? Esse ServiceLayer o que seria? Eu sei que estou embolando os conceitos… mas tudo bem… vou tentar falar o que entendi:
Na view sendo um jsp tem um cadastro de usuários, essa ação é enviada para o FrontController que chama a action específica para adicionar um usuário(AddUsuarioAction?? AddUsuarioCommand?? heh), esse por sua vez chama tipo o HibernateValidator como tu mencionou ou faço as validações do mesmo… dae é que entra outra história… A minha classe Usuário, o que ela deve saber de si mesma… ela deve saber se cadastrar?? Tipo…
usuario.cadastroUsuario();? Dae esse cadastroUsuario chamaria o Repositorio e tal…
Tenta dar uma arrumada nessa salada que estou fazendo… pois tem algumas coisas que estão meio confusas… pois eu estava acostumado a seguir a seguinte logica… View(jsp)----> FrontController(Delega as requisições) ----> Commands(Ex: AddUsuarioCommand - Validação dos dados etc ) -----> UsuarioBO-UsuarioVO e o UsuarioBO chamando o UsuarioDAO… tipo… eu estou vendo que tem muita coisa desnecessária aí… redundancia e tal… eu queria dar uma arrumada nessa forma que eu faço hoje… pois vejo que isso é totalmente procedural e nada OO!
Valeu!
Ops… ví que você alterou a sua mensagem bem em cima do que eu perguntei… então como seria o objeto Usuario??
Abraço!
O FrontController já vai vir no framework, a não ser que você mesmo crie o seu framework web, o que eu acho que não vale a pena.
Seu Command/Action vai usar algo da infra do framework, seja via implementação de interfaces, herança, Annotations, config no xml.
O objeto usuário ter um método para se cadastrar é possível. O Pattern se chama ActiveRecord. Sinceramente não vejo as pessoas implementanto isso em Java por outras questões que não vem ao caso. O mais comum é utilizar um Repository. Ex: UsuarioRepository ou RepositorioUsuarios, como queira chamar. Este teria as operações responsáveis para armazenar seus usuários. Ex: adicionar, remover, etc.
Humm. ok… vamos supor que os actions são não mão mesmo… dae no caso nele eu posso colocar as regras de interface, digo, validação dos dados etc?? E outra… seria o command que chamaria o repositório??
E sobre o repositório, eu dei uma lida, o repositório é um local onde os objetos serão guardados, e como entra a questão do repositório e DAO, vamos supor que os dados serão persistidos… o meu repositório vai chamar o DAO ou ele mesmo será tipo uma implementação do DAO?
Valeu!
O Command/Action pode chamar o Repositório ou dependendo do seu caso você pode ter uma Service Layer no meio do caminho. Pra simplificar esquece a Service Layer por enquanto e seu Command chama o Repositorio.
Repositório geralmente é apenas uma interface e o DAO implementa ele.
Acho interessante você ler este livro, fará você entender os conceitos da coisa: