Alguém poderia dar uma breve descrição ou indicar links sobre esse tema?
valeu
“VO”? … desculpa a ignorância, mas é sigla do q? :oops:
Value Object (VO) é um Java Bean, ou seja, é uma classe serializável que contém atributos com seus métodos sets e gets.
Exemplo na prática: Se vc quer trocar informações através de uma rede, por exemplo, vc cria um VO com os dados que serão transportados. Outro exemplo: Quando vc faz um insert na DAO, por exemplo, vc terá que passar os dados da tabela de alguma forma, é ai que entra a VO. Vc cria uma VO com os campos da Tabela relacionada a DAO.
Dessa forma por exemplo eu teria:
Cidade com os atributos codigo, descricao com os gets e sets
e RnCidade que executa as operações insert, update e queries separadamente?
É isso?
RN = Regra de negócio
Na verdade é no DAO que vc faz os inserts, updates, deletes e selects.
Uma nova pergunta: Qual a estrutura de que vcs usam?
Eu uso assim, por exemplo:
ProdutoDAO (interface)
ProdutoDB (classe concreta que implements ProdutoDAO)
Produto (VO com os atributos PRIVATES e gets/sets)
Uso uma DAOFactory que me retorna a implementação do DAO.
Na Produto não tenho regras de negócio, e tenho outras classes que contém a regra de negócio que interagem com o DAO e a VO.
Olá,
estrutura q eu uso:
3 camadas, MVC
2° Camada (Control)
FrontController
AddProduct extends FrontController, EditProduct extends FrontController, etc. Os FrontControllers são quem chamam os Business Objects. Geralmente uso Struts nesta camada.
3° Camada (Model)ProductDao(Interface)
Esta camada eu divido em duas. Business Object(BO ou RN) e Data Access Objects(DAO).
ProductDomain(Business Object) - Este objeto é quem acessa os DAOs e executa outras lógicas de negócio(com overificação de permissão, log, cache, etc).
ProductRdbDao implements ProductDao - Implementação do DAO para acesso a banco de dados relacionais.
ProductXmlDao implements ProductDao - Implementação do DAO para acesso a banco de dados em XML.
Notei nas mensagens que vocês não estão usando Business Objects. Lembrem-se que o Pattern DAO não deve ser usado diretamente. Segundo a definição ele deve abstrair o acesso a dados dos objetos, nada a mais além disto. Portanto a lógica do negócio, a inteligência do sistea, não deve estar dentro de um DAO.
Seguinte Franklin,
A estrutura da minha aplicação é a seguinte exemplificando:
:arrow: CidadeFm - Tela de cadastro de cidades.
:arrow: CidadeRn - BO que vc se referiu abrasileirado para Regra de Negócio. Cuida para que os dados estejam todos preenhidos corretamente.
:arrow: Cidade - VO com os atributos PRIVATES e gets/sets
:arrow: CidadeDAO - Interface que defini os métodos: salvar(cidade), excluir(int codigo), getList(), getCidade(int codigo);
:arrow: CidadeDbAO - Implementa a interface CidadeDAO executando a persistência no BD. Tem a função de pegar conexão, …
Sequência:
CidadeFm Tem instência de CidadeRn e Cidade (VO)
|
CidadeRn Tem instância de CidadeDbDAO
|
CidadeDbDAO Acessa o BancoQue tal dessa forma?
conciani, vc poderia postar um exempo de DAOFactory. Já li um monte de conceitos mas nunca achei um exemplo esclarecedor.
Valeu
Exemplo de DAOFactory:
[code]public class DAOFactory {
private static final String prefixo = "com.minhaemprsa.meusistema.db.";
private static final String sufixo = "DB";
public static MeuSistemaDAO getDAO(String nomeEntidade) throws MinhaException{
System.out.println("Fazendo DAO em : " + nomeEntidade);
Class classe = null;
MeuSistemaDAO dao = null;
try {
classe = Class.forName(prefixo + nomeEntidade + sufixo);
dao = (MeuSistemaDAO)classe.newInstance();
} catch (Exception e){
throw new MinhaException("Erro ao criar objeto DAO: " + prefixo + nomeEntidade + sufixo);
}
return dao;
}
}[/code]
Todos as minhas interfaces DAOs extends a interface MeuSistemaDAO.
Para usar isso:
ProdutoDAO dao = (ProdutoDAO)DAOFactory.getDAO("Produto");
Observação: MeuSistemaDAO é apenas didático.
Quando digo que “Na Produto não tenho regras de negócio, e tenho outras classes que contém a regra de negócio que interagem com o DAO e a VO.”
quero dizer que essa lógico de negócios não está contido no DAO. Mas eu chamo isso de BD (Business Delegate),
não sabia que se chamava BO(Business Object). Alguém sabe dizer qual é a diferença entre elas?
Ao moderador: Dá pra redirecionar essas msgs para o forum de Design Patterns?
MeuSistemaDAO é uma interface? Vc poderia esclarecer?
Quanto a Minha Exception criei um DAOFactoryException e tratei da mesma na classe de regra de negócio a que o DAO pertence.
Olá,
conciani,
é isto aí mesmo. Cada um faz uma modificação para seu sistema mas o groso de uso de MVC com Design Patterns é isto mesmo.
Só para apimentar mais um pouco: Também é comum, principalmente em sistemas que usam EJBs, usar o Pattern Business Delegate, junto com outros patterns conhecidos como o Service Locator. O Business Delegate é usado para abstrair chamadas remotas. Ou seja, ao invés de sua camada controle fazer uam busca na rede via JNDI, procurando por um EJB(Business Object), é usado um Business Delegate. Assim a cama controle não conhece mais nos BOs. A camada Control conhece um Delegate, o delegate faz toda a “borracharia” para encontrar o BO(que neste caso é um EJB) e daí para frente segue igual.
Sobre as Factories:
Estou gostando muito do conceito de Inversion of Control(IoC). Quem gosta de usar o Pattern Factory, deveria dar uma olhada em IoC. Basicamente IoC faz todos seus objetos serem acessados por factories. Obviamente há muitos outros conceitos por trás de IoC…
Em particular tenho estudado bastante o Springframework.org. Ele tem suporte à IoC, entre outras coisas.
Estamos estudando ele para colocar no JNuke.
MeuSistemaDAO é uma interface, só para facilitar e não ter que fazer o casting dentro da aplicação e també garantir que o objeto retornado será um DAO.
“O Business Delegate é usado para abstrair chamadas remotas”
Nossa, tá fogo esse negócio! Eu achava que isso era o Facade!
Já que vc tocou no assunto: Fale mais sobre IoC.
Olá Mônica,
O Facade e o Delegate tem muitas semelhanças, na maiora dos sistemas q conheço o mesmo objeto tem faz o papel dos dois. Um delegate por natureza é um Facade.
A diferença mais significativa entra Delegate e Facade, é que o Delegate abstrai a complexidade da chamada de métodos de negócio. Enquanto que o Facade é para abstrair a complexidade de um fluxo, ou workflow.
Delegate vc usa sempre para chamar um BO.
Facade vc usa quanto precisa disponibilizar uma forma simples de acessar vários métodos de negócio. Por exemplo: inserir usuário e enviar e-mail. São duas operações, mas para que os objetos clientes não precisem conhecer dois BOs("Criador de usuários"e “enviador de mail”) e usado um Facade. Assim o cliente conhece apenas um metodo do Facade, e não se preocupa em como funciona a camada de negócios.
Cliente == Interface gráfica, camada controle, ou qq outra traquitana q acesso Busines Objects(BO).
Resumindo:
Delegate: Abstrai para o clinete, detalhes de como é implementado um Objeto de Negócio.
Facade: Abstrai para o cliente a compexidade entre workflow de Objetos de Negócio
Links para os dois patterns:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
Sobre IoC, não sou nenhum expert. Ainda é novo para mim. Podemos conversar mais sobre IoC em um outro tópico, para não misturarmos os assuntos deste. Ok?
Tb costumo fazer dessa maneira conciani.