14/09/13

DAO | Srgio Taborda's Weblog

Srgio Tabordas Weblog

Alguns ensinam. Alguns fazem. O resto procura nos livros. Incio Blog Cincia Desenvolvimento

Entretenimento

Epistemologia Poltica

Type text to search here...

DAO
Deixe o seu comentrio Go to comments

DAO
O padro Data Access Object (DAO) um padro introduzido no ambiente JEE [3] para simplificar e desacoplar a interao das aplicaes Java com a API JDBC.

O problema
A maioria (para no dizer todas) das aplicaes de nvel corporativo usam algum tipo de persistncia de dados. Entre eles o mais usado o Banco de Dados e a linguagem SQL amplamente utilizada para comunicar com os sistemas gerenciadores de banco de dados. Java suporta esta necessidade desde cedo com o advento da API JDBC (Java Database Connectivity). Antes do uso de Java em sistemas corporativos as aplicaes eram majoritariamente escritas em linguagens orientadas a processo e a ordem e instrues SQL especficas continham regras de negcio. Ao passar esses sistemas para Java, essas regras no se poderiam perder e, ao mesmo tempo, h que se trabalhar com objetos. O padro DAO visava originalmente encapsular esses conjuntos de cdigos SQL que existiam em aplicaes legadas[3]. Esse cdigo continha regras tanto na pesquisa dos dados, tanto na edio dos dados. comum ao inserir um determinado dado, ter que inserir ou atualizar outros. Para projetos novos, que no dependem de cdigo legado, JDBC a escolha para comunicar com bancos dados. Contudo o uso de JDBC obriga as aplicaes Java, a escrever SQL para comunicar com o gerenciador de bando de dados. Essa comunicao feita utilizando o padro Bridge em que a interface Java e igual para todos os sistema de gerenciamento de bancos de dados e a implementao especfica de cada um encapsulada no conceito de driver. O problema que nem todos os drivers JDBC suportam todos os tipos de instruo SQL, ou nem sempre com o mesmo dialeto. Alguns suportam operaes que outros no. Java orientado a objetos e mapear as propriedades dos objetos para tabelas utilizando SQL
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 1/14

14/09/13

DAO | Srgio Taborda's Weblog

processo chato, demorado, passvel de erro e que ningum quer repetir em diferentes pontos da aplicao. Finalmente, nem todas as aplicaes comunicam apenas com banco de dados. Algumas podem comunicar com servidores LDAP ou servios externos Business-to-Business (B2B), por exemplo. Esta comunicao muitas vezes elaborada depois que a aplicao est em produo substituindo o banco como fonte de dados. As API para comunicao com estes sistemas so diferentes do JDBC quem em termos de interface quer em termos de filosofia. O problema tem na realidades trs perspectivas: Legado : Queremos encapsular lgicas de persistncia legadas escritas com SQL ou outras tecnologias de forma simples. Queremos apenas utilizar as tecnologias java, mas manter as mesmas regras de negocio Isolamento : Queremos que a aplicao seja isolada da API com que est comunicando. Queremos poder alterar a API sem alterar a aplicao. No caso de JDBC queremos utilizar a mesma API para comunicar com diferentes gerenciadores de bando de dados sem alterar a aplicao. Mapeamento de Objetos : Qeremos utilizar objetos no ambiente Java. Queremos poder utilizar os mesmos objetos independentemente da API de persistencia.ORM (Object-Relational Mapping) Mapeamento ObjetoRelacionamento o mapeamento mais comum, mais outros mapeamentos so possiveis, como para XML, LDAP ou WebServices. Os mapeamentos ORM podem ainda mudar quando mudamos de gerenciador de banco de dados

A soluo
O padro DAO soluciona estes problemas de uma forma simples. Todas as comunicaes com o mecanismo de persistncia so mediadas por um objeto o DAO. Esse objeto mapeia informaes transportadas em objetos (Tranfer Object) para instrues da API de persistncia e mapeia resultados obtidos dela de volta para os mesmos objetos de transporte. Toda a lgica de mapeamento e execuo das instrues deixada dentro do objeto DAO desta forma isolando a aplicao da API de persistncia por completo. O objeto DAO responsvel por operar o mecanismo de persistncia em nome da aplicao tipicamente executando os quatro tipos de operaes Criar, Recuperar , Alterar, Apagar conhecidas pela sigla CRUD do ingls Create, Retrive, Update , Delete. As operaes de edio so invocadas diretamente passando o objeto com as informaes a serem editadas. As operaes de recuperao so normalmente implementadas como mtodos especficos. Por exemplo, recuperar o objeto que corresponde com uma certa chave, ou critrio de busca. Estes mtodos contm regras de negocio diferentes conforme o tipo de dados sendo persistido. Em particular pode no existir nenhuma regra particular, ou a regra s poder ser executada em um tipo especifico de API de persistncia.

Interface
interessante que o DAO seja especificado atravs de interface ao invs de uma classe concreta. Desta forma, no s facilitamos o trabalho de implementar novos mecanismos de persistncia, mas tambm, impedimos que se criem referencias a classes concretas, diminuindo o acoplamento a um mecanismo em particular. Se estamos utilizando diferentes DAO conforme o mecanismo de persistncia que queremos usar, temos que ter alguma forma de escolher qual utilizar. Se voc estiver utilizando algum framework de injeo de dependncia (DI), basta configur-lo para injetar a implementao certa. Outra opo (que no incompatvel com a anterior) o uso do padro Factory Estes padres funcionam melhor se utilizarmos interfaces seguindo o Principio de Design por Contrato. A interface do padro original simples. So fornecidos mtodos para as operaes CRUD, sendo que a operao de recuperao distribuda em diferentes mtodos de pesquisa especializados. So estes mtodos especializados que encapsulam facilmente lgicas de pesquisa de sistemas legados. 01 02 03 public class Customer { 04 // atributos 05 // acessores e modificadores
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 2/14

14/09/13

DAO | Srgio Taborda's Weblog

06 07 } 08 09 public interface CustomerDAO { 10 11 Customer create () ; 12 void insert ( Customer c ) ; 13 void update ( Customer c ) ; 14 void delete ( Customer c ) ; 15 Customer findByID ( Integer id ) ; 16 Customer finfByCustomerNumber ( String customerNumber ) ; 17 } 18 19 public class JDBCCustomerDAO implements CustomerDAO { 20 21 public Customer create (){ 22 return new Customer () ; 23 } 24 public void insert ( Customer c ){ 25 // usa JDBC para criar e executar uma frase SQL de inserso. 26 } 27 public void update ( Customer c ){ 28 // usa JDBC para criar e executar uma frase SQL de atualizao. 29 } 30 public void delete ( Customer c ){ 31 // usa JDBC para criar e executar uma frase SQL que remove o cliente do banco 32 } 33 public Customer findByID ( Integer id ){ 34 // usa JDBC para criar e executar uma frase SQL que pesquisa o cliente com a chave passada. 35 } 36 public Customer finfByCustomerNumber ( String customerNumber ){ 37 // usa JDBC para criar e executar uma frase SQL que pesquisa o cliente com o numero passado. 38 } 39 }

Cdigo 1: O mesmo cdigo teria que ser repetido para todos os tipos de objeto persistido. Coloquei o mtodo create() explicitamente na interface do DAO porque ser importante mais frente. Por agora ele simplesmente cria o objeto algo que poderamos fazer facilmente fora do DAO. Esta utilizao do padro Factory Method parece ftil, mas como veremos depois importante para alguns tipos especiais de implementao do padro DAO.

Sabores de DAO
Existem vrios sabores de DAO. A razo para isto que o padro DAO no muito prtico quando o sistema tem muitos objetos persistentes.

DAO padro
Vimos como seria a implementao padro[3] do DAO. Para cada tipo de objeto de transporte (TO) Cliente, Pedido , etc existe um objeto DAO correspondente. Os objetos DAO formam uma camada na aplicao[1]. A aplicao tem que invocar o DAO certo para trabalhar com o objeto de transporte certo. Cada objeto DAO sabe como ler e popular as propriedades do TO e us-las na API do mecanismo de persistncia que est usando.
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 3/14

14/09/13

DAO | Srgio Taborda's Weblog

Neste sabor do padro os objetos DAO formam um camada espessa recheada de lgica de mapeamento misturada com lgica de persistncia e lgica de negcio. Alm disso ele cria a necessidade de um conjunto muito grande de classes distribudas no seguintes tipos: TO Objetos de transporte. Eles so encarregados de manter os dados em memoria na forma de objetos e estruturas de objetos. Exemplo: Customer Interface DAO Interface para o DAO de um certo tipo de TO. Exemplo: CustomerDAO Implementao DAO Implementao da interface para o DAO de um certo tipo de TO e um certo tipo de API de persistncia. Exemplo: JDBCCustomerDAO Factory de DAO Fabrica que sabe qual implementao utilizar para cada interface. Na realidade a fabrica uma metfora para o mecanismo de mapeamento entre a interface e a implementao. Utilizando um mecanismo de DI teramos de as mapear igualmente, apenas o faramos de forma diferente. Se o seu sistema tiver 10 tipos de objeto persistente (10 tabelas) voc precisa escrever 30 classes s para comear.

DAO Genrico
Voc pode estar pensando que usando tipos genricos poderamos diminuir a quantidade de interfaces e implementaes necessrias. Na realidade isso no bem verdade, porque as interfaces do DAO contm mtodos de procura especficos dependentes do objeto de transporte , das regras de persistncia e de regras de negocio. Usando tipos genricos neste estgio no nos ajuda a diminuir o nmero de classes ou simplificar a implementao mas no ajuda a diminuir o numero de mtodos por interface DAO utilizando interfaces comuns (padro Separated Interface [1]). 01 02 03 public interface GenericDAO<T> { 04 05 T create () ; 06 void insert ( <T> obj ) ; 07 void update ( <T> obj ) ; 08 void delete ( <T> obj ) ; 09 T findByID ( Integer id ) ; 10 11 } 12 13 public interface CustomerDAO extends GenericDAO<Customer> { 14 15 Customer finfByCustomerNumber ( String customerNumber ) ; 16 } Cdigo 2: Diminuimos a quantidade de mtodos na interface DAO especifica de cada objeto de transporte, mas no ganhamos muito. Criamos mais uma classe e a implementao ainda continua especfica.

DAO + Bridge
At agora deixamos os objetos de transporte serem explicitamente classes. Isto na realidade um problema. Todas as implementaes do DAO para as vrias tecnologias esto foradas a utilizar o mesmo objeto. Se o objeto mudar (por exemplo, adicionarmos um campo) todas as implementaes de DAO para as vrias tecnologias tm que mudar. Para evitar este problema aplicamos o padro Bridge deixando as implementaes e as interfaces serem definidas independentes.Para isso utilizamos interfaces em vez de classes para especificar os nossos objetos de transporte[3]. Como estamos utilizando o padro Factory Method para obter os objetos de transporte, podemos agora retornar uma implementao especifica da implementao do DAO. Com isto podemos fazer muitos tipos de otimizao. Por exemplo,
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 4/14

14/09/13

DAO | Srgio Taborda's Weblog

podemos incluir uma lgica que nos permite saber se os valores dos dados mudaram. Isso ajudar no mtodo de atualizao. Se no mudou nada simplesmente no faz nada e poupa a comunicao com o banco. Quando a implementao controla todos os fatores fcil fazer otimizaes. Esta tcnica utilizada pela prpria API JDBC para desacoplar a aplicao Java do gerenciador de banco de dados permitindo que este faa as otimizaes que achar necessrias. DAO + Bridge + Proxy Como no existe nenhuma outra lgica nos objetos de transporte que no seja ler e escrever os seus atributos podemos utilizar uma implementao genrica baseada num mapa atributo=valor utilizando o padro Proxy. Basicamente utilizamos um Map e o encasuplamos dinamicamente na interface do objeto de transporte esperado. Isto relativamente simples de fazer utilizando a classe java.lang.reflect.Proxy da API padro do JSE. A utilizao do padro Bridge no nos ajuda a diminuir classes, mas ajuda na implementao. Podemos ter controle total sobre como implementamos os objetos DAO e como comunicamos com a API de persistncia. Isso permite que utilizemos otimizaes, entre as quais o uso de Proxy para os objetos de transporte. Retirando efetivamente da aplicao o trabalho de os codificar e manter.

DAO + Metadados
Para reduzir o nmero de implementaes necessrias, ou pelo menos diminuir a implementao de mtodos comum necessrio termos a informao descrita de uma forma mais abstrata. Temos que utilizar metadados. Existem dois tipos de metadados que podem ser usados, no necessariamente excludentes. Podemos utilizar metadados existentes na prpria estrutura das classes. Este uso normalmente referido como Introspeco (Introspection um tipo particular de Reflection) Por exemplo, no usar new na classe e usar os mecanismo de do Java para criar o objeto a partir da sua classe. ( se utilizarmos o mecanismo de proxy descrito antes j estaremos fazendo isto implicitamente) Outro exemplo utilizar introspeco para ler e escrever os atributos dos objetos dinamicamente invocando os mtodos get/set dinamicamente. Para que o mecanismo de introspeco funcione a implementao do DAO precisa previamente saber a classe do TO. Outra forma de metadados so aqueles relacionados estrutura persistente do objeto. No caso de bancos de dados seriam os metadados das tabelas e seus relacionamentos. Podemos deixar responsabilidade da implementao do DAO descobrir e utilizar os metadados. Uma melhor opo utilizar o padro MetadataMapper deixando essa responsabilidade para outro objeto. Este objeto pode simultaneamente obter informaes da estrutura de classes como ser configurado com informaes extra sobre relacionamentos e tabelas. Com metadados a implementao dos mtodos bsicos comum a todos os tipos de objeto de transporte, simplificando a implementao do DAO. Essas implementaes comuns podem ser encasupladas num classe pai de todos os DAOs. Os DAO especficos podem estender esta classe se necessrio para prover mais mecanismos de busca, ou alterar os mecanismos padro. 01 02 03 public class AbstractDAO<T> implements GenericDAO<T> { 04 05 MetadataProvider metadata; 06 public AbstractDAO ( MetadataProvider metadata ){ 07 this .metadata = metadata; 08 } 09 10 public T create (){ 11 return metadata.getTOClass () .newInstance () ; 12 } 13 14 public T findOne ( QueryObject<T> q ){
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 5/14

14/09/13

DAO | Srgio Taborda's Weblog

15 // traduz q para SQL usando os metadados 16 } 17 18 19 } Cdigo 3: O nmero de classes diminuiu. Agora podemos utilizar sempre AbstractDAO apenas constituindo classes especificar quando existem mtodos ou regras especificas a serem implementadas. A utilizao de fabricas ou DI vital para o sucesso desta abordagem porque podemos retornar uma instncia de AbstractDAO devidamente configurada para um TO particular. Apenas em casos particulares precisaremos retornar alguma classes especial. E quando tivermos que fazer isso poderemos aproveitar a maioria dos mtodos via herana.

DAO + QueryObject
Aquilo que separa ainda de implementaes ainda mais genricas para o padro DAO so os mtodos especiais de pesquisa. Criar um mtodo para cada estratgia de pesquisa aumenta rapidamente a interface do DAO. Isso mau pois estamos aumentando a responsabilidade dos implementadores da interface. Isso obriga a que todos os DAO de todos os mecanismos implementem esses mtodos. Inadevertidamente podemos criar mtodos que certos tipos de persistencia no podem executar. Mesmo com o padro Bridge, isso pode ser complicado de gerenciar. Para solucionar isso podemos invocar o Principio de Separao de Responsabilidade (SoC) e abstrair a logica de pesquisa num objeto parte. Estas vrias estratgias de pesquisa podem ser utilizadas por DAO de diferentes tipos e at mesmo para diferentes mecanismos de persistencia. Em particular podemos criar implementaes de Query Object que permitam as operaes mais comuns. Deixando para os mtodos especiais apenas aquelas que no podem ser traduzidas pelo Query Object. Sendo que SQL uma linguagem de pesquisa genrica normalmente possvel explicitar a maioria das opes utilizando uma implementao de Query Object O numero de mtodos especficos que ainda teriam que ser criados nas interfaces especificas dos DAO diminuem na razo inversa do poder de abstrao da sua implementao de Query Object.Ou seja, quanto mais poder usar Query Object menos usar mtodos especficos. 01 02 03 public interface GenericDAO<T>> { 04 05 T create () ; 06 void insert ( <T> obj ) ; 07 void update ( <T> obj ) ; 08 void delete ( <T> obj ) ; 09 List<T> findAll ( QueryObject<T> criteria ) ; 10 T findOne ( QueryObject<T> criteria ) ; 11 } 12 13 DAO Genrico com QueryObject Cdigo 4: DAO Genrico com QueryObject A utilizao destes objetos de pesquisa pode facilmente distribuir logicas de pesquisa por toda a aplicao. Para que isso no acontece voc pode utilizar o padro Repository que mantm as pesquisa num s lugar. O uso de Query Object simplifica a interface do DAO diminuindo o numero de mtodos de pesquisa especificos.

Referncias
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 6/14

14/09/13

DAO | Srgio Taborda's Weblog

[1] Patterns of Enterprise Application Architecture Martin Fowler et. al. URL: http://www.martinfowler.com [2] Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides URL: 1995 Addison-Wesley [3] Core J2EE Patterns Data Access Object Sun Developer Network URL: http://72.5.124.55/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Licena
Srgio Taborda Este trabalho licenciado sob a Licena Creative Commons Atribuio-Uso No-Comercial-No a obras derivadas 3.0 Genrica . Gosto
Be the first to like this.

Comentrios (9) Trackbacks (0) Deixe o seu comentrio Trackback 1. Marcos Urata 2008/09/19 s 9:57 | #1 Resposta | Citao Sergio, interessante seu artigo. S no entendi uma coisa, em um forum do GUJ, vc diz que um erro o uso do Hibernate como uma possivel implementao do DAO. Eu no entendi pq vc afirmou isso ainda mais aps ler esse seu artigo que diz que uma das motivaes de se utilizar o DAO abstrair a parte de mapeamento de objetos. Outra coisa, na sua opinio, ser que realmente ter esses DAOs extremamente genricos, usando metadados e outros recursos, reduzindo a quantidade de classes de implementao? Acho que o cdigo fica complicado de entender e com certeza no deve ser to performtico quanto escrevendo DAOs especficos para cada entidade. Enfim, qual cenrio seria interessante usar essas implementaes genricas? Outra coisa, na sua opinio, ser que realmente vale a pena ter esses DAOs extremamente genricos, usando metadados e outros recursos, reduzindo a quantidade de classes de implementao? Acho que o cdigo fica complicado de entender e com certeza no deve ser to performtico quanto escrevendo DAOs especficos para cada entidade. 2. sergiotaborda 2008/09/19 s 11:00 | #2 Resposta | Citao O erro de embrulhar o Hibernate com o DAO conceptual. O hibernate uma implementao do padro DomainStore. Este padro visa simplificar a persistencia de um modelo de dominio OO. O DAO no visa isso. Ele visa simplificar a comunicao com uma API de persistencia. Isso inclui, por exemplo, a chamada a sotreprocedures
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 7/14

14/09/13

DAO | Srgio Taborda's Weblog

de forma transparente que no o objetivo do DomainStore. Ao colocar o DomainStore dentro do DAO vc est tentando criar um forno a lenha que usa na realidade um micro-ondas internamente. no faz sentido esse tipo de encapsulamento. O DAO no serve para abstrar Mapeamento OR embora possa ele serve para abstrair o acesso a dados ( quaisquer dados, em qualquer formato, no necessariamente OO). O objetivo no criar um DAO para cada entidade. Isso prolixo e no fim, intil. O cdigo dentro dessas classe sempre igual . Por isso o DomainStore apareceu (naturalmente como evoluo do DAO). Ele j sabe que o cdigo sempre o mesmo e fornece mecanismos para que vc no tenha que o escrever. Assim o DAO sobra apenas como um padro de importncia histrica e sempre que vc tiver uma comunicao com sistemas legados cuja interface atravs de um banco de dados (que foi o problema que levou, inicialmente, ao uso e criao do padro DAO). Tentei demonstrar no artigo que podemos entender o DomainStore como uma evoluo natural do DAO mas que chegado em certo ponto necessrio injetar conhecimento do domnio. ai que a responsabilidade do DAO quebrada porque ele no pode saber do domnio. Ento o objeto de acesso a dados se torna no objeto de acesso a entidades de um domnio persistidas em algum armazm (store) o Data Access Object vira o Domain Store que um objeto com responsabilidades diferentes. Na minha opinio , se o seu sistema no interage com sistemas legados , vc deve esquecer que existe o DAO. Deve simplesmente usar um DomainStore ( tem alguns j implementados como o Hibernate ou o JPA, ou fazer o seu) para o acesso persistente e um camada de Repositrios para incluir as lgicas. Aqueles mtodos que vc coloca no DAO para montar uma query , envi-la ao banco e tratar o resultado de forma a ser devolvido num objeto simples ( um List,por exemplo) deve ser feito no Repositrio. Ele usa a API de critrios do DomainStore que equivalente a escrever SQL, envia ao DomainStore e ele lhe retorna o resultado que vc ento trata para retornar o que vc quer (um List, normalmente) S existe uma nica razo para usar DAO: acessar um sistema legado. D uma olhada no artigo Arquitetura Orientada ao Domnio para mais detalhes. 3. Marcio Duran 2009/08/11 s 9:58 | #3 Resposta | Citao Bom dia Sergio, No que voc colocou !!! O DAO no serve para abstrar Mapeamento OR embora possa ele serve para abstrair o acesso a dados ( quaisquer dados, em qualquer formato, no necessariamente OO). Pergunto, O DomainStore diz respeito a entidades ? posso dizer que essas entidades so objetos de infraestrutura(usam mecanismo de frameworks), em vista que voc j afirmou que o DAO seria uma classe abstrata ou at mesmo o repositrio, todavia o DAO recupera informaes de dados, esse dados so entidades que diz respeito a Dominio para que contexto no diz respeito mas o DAO acessa sistema legado usando que mecanismo o DomainStore. Talvez eu tenha feito uma salada de ideias, mas no fim quero saber se existem objetos de dominio e se so entidades e se existem objetos de infraestrutura se so o DomainStore, ou se o termo que estou querendo empregar equivocado ou estou fazendo confuso sobre conceitos. Abraosss

sergiotaborda 2009/08/11 s 10:36 | #4 Resposta | Citao

sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 8/14

14/09/13

DAO | Srgio Taborda's Weblog

Um domainStore um armazm de dominio. Essa a traduo literal que encaixa muito bem. O DomainStore guarda entidades do dominio. Entidades so do dominio. No so de infraestrutura. Mesmo que o seu DOmainStore seja implmentado por um API de terceiros ela no cabe como infra. Dados no so entidades. So dados: numeros, palavras, datas. Entidade algo mais. ter uma identidade. Ser nico no sistema. Pessoas podem ter os mesmos dados ( mesmo nome, data de nascimento) e mesmo assim serem diferentes pessoas. Entidade um conceito abstrato que pertence ao dominio. Dado um conceito concreto que pertence aplicao. DAO no usam DomainStore. DomainStore que usa DAO ( internamente) O acesso a sistemas legados s pode ser feito se o sistema legado OO e contm o conceito de dominio. Caso contrrio um sistema orientado a dados e o DomainStore inutil. Objetos de Dominio so todos aqueles que participam do dominio. Existem vrios. Cada uma com responsabilidades diferentes. Eles implementam vrios padres como Entidade , Servio, Objecto de Valor, Repositorio e Validador. A implmentao destes pode ser feita custa de API j existentes, mas isso no os torna objetos de infra. Entidades so objetos de dominio, mas nem todos os objetos de dominio so entidades. Alguns so servios, por exemplo.

Marcio Duran 2009/08/11 s 11:20 | #5 Citao Excelente explicao Sergio, !!!! Mas questionando um pouco mais, o que eu poderia relevar a objetos de infra ? Poderiam ser componentes ?!isso no se encontra dentro da minha aplicao ?! Em outra questo voc colocou Entidades so objetos de dominio, mas nem todos os objetos de dominio so entidades.Alguns so servios.Quando voc se reporta a servios algo sobre SOA ? + uma vez Obrigado !!!!

sergiotaborda 2009/08/11 s 11:30 | #6 Citao Objetos de infra fazem coisas to genricas que servem para todas as aplicaes. Por exemplo, um servlet um objeto de infra. SOA uma camada de servios de aplicao. Uma aplicao fornece servios para outra. Servios de dominio algo mais interno. Um webservice, por exemplo, um servio de aplicao. Internamente ele pode invocar um servio de dominio ou vrios. Ha uma relao entre os dois tipos de servio, mas no 1 para 1.

Marcio Duran 2009/08/11 s 11:50 | #7 Citao Obrigado Sergio, Agora ficou melhor esclarecido, so esses detalhes que agente no percebe e que fazem muita diferena no entendimento !!! Abraooo !!!
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 9/14

14/09/13

DAO | Srgio Taborda's Weblog

4. sfidencio 2010/12/02 s 14:40 | #8 Resposta | Citao sergiotaborda : Objetos de infra fazem coisas to genricas que servem para todas as aplicaes. Por exemplo, um servlet um objeto de infra. SOA uma camada de servios de aplicao. Uma aplicao fornece servios para outra. Servios de dominio algo mais interno. Um webservice, por exemplo, um servio de aplicao. Internamente ele pode invocar um servio de dominio ou vrios. Ha uma relao entre os dois tipos de servio, mas no 1 para 1. Srgio parabns, acompanho sempre no GUJ e no seu BLOG tuas articulaes acerca de arquitetura, patterns, metodologias, paradigmas, efim parabns, considero voc um gnio e bastante conheedor principalmente de padres de projeto, inclusive os do Domain Driven Design. Efim as minha perguntas so simples: 1. Levando em conta que o Hibernate uma implementao da API de persistncia do JAVA ou JPA, assim como outros providers de ORM, posso afirmar que internamente tais providers implementam o padro DomainStore ? Exemplo: //Esse tambm artefato de dominio. Tenho a Entidade Cliente.java, essa por sua vez possui seguinte regra de negocio. public class Cliente { //O Spring injeta pr mim a implemetao que no caso est na camada de infra ou //seja o DAO podre que voc fala para cada entidade. private ClienteRepository clienteRepository; public List obterContasReceber(Date dataInicial, Date dataFinal) { if(dataFinal.before(dataInicial)) { thow new exception(Data final deve ser maior que inicial); } //O Rodrigo Yashima questionou no blog dele acerca de prefixar nome do //repositorio com repository. segundo ele, pr denotar a realidade do //do dominio deveria chamar Clientes pois trata de repositorio de clientes //Tambm concordo, at pr preservar a Linguagem Onipresente que prega o DDD return this.clienteRepositoty.obterContasReceber(dataInicial,dataFinal); } } Repositorio de Cliente. //Esse cara artefato de dominio. public interface ClienteRepository { public List clienteenteRepositoty.obterContasReceber(dataInicial,dataFinal); } ================================================================================ //Arqui vem a bagulhada de infra.
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 10/14

14/09/13

DAO | Srgio Taborda's Weblog

//No sou muito f de Generics e Reflections. o tipo da list poderia ser T public class ClienteDAOImp implements ClienteRepository { public List obterContasReceber(dataInicial,dataFinal) { //Empreender toda logica pr acessar o SGBD..e retornar os objetos //Para as camadas que impusionaram a chamada. } } Eu tinha t criado uma interface IClienteDAO que fosse implementada por essa classe ClienteDAO, visando abstrair o SGBD, entretanto, com lendo sobre DDD, vi que isso no necessrio uma vez usando esse padres. Agora vem a pergunta Sergio, Eu posso elimiar esse nome DAO mesmo usando SQL Puro..? ficaria assim. //Arqui vem a bagulhada de infra. //No sou muito f de Generics e Reflections. o tipo da list poderia ser T public class ClienteRepositoryImp implements ClienteRepository { public List obterContasReceber(dataInicial,dataFinal) { //Empreender toda logica pr acessar o SGBD..e retornar os objetos //Para as camadas que impusionaram a chamada. } } Ou seja, ao invs de chamar ClienteDAOImp, se chamada ClienteRepositoryImp e herda/implementa de ClienteRepository agora te pergunto, esse ClienteRepositoryImp ficaria na camada de infra ou domain ? Observe que estou a utilizar JDBC puro sem framework nenhum de ORM,. seria correta deixar a implemetao do repository que nada mais que um DomainStore, por exemplo um EntityManager da JPA um objeto do DomainStore concorda? ou seja, deixar essa implementao dentro do Domain Model ? e eliminar esse objeto DAO ? tem como voc citar exemplos? Se possivel envie um diagrama de sequencia de uma caso de uso qualquer.que use JDBC puro sem ORM. sfidencio@gmail.com Att fidncio.

sergiotaborda 2012/04/11 s 20:54 | #9 Resposta | Citao sfidencio, peo desculpa porque s vi a sua pergunta hoje. De alguma forma escapou nos avisos do wordpress. O problema que coloca relativo a repositorios que usam SQL puro por baixo dos panos. Em tese um repositorio pode usar qualquer tecnologia que quiser , mas no diretamente. Normalmente o Repositorio delega ao DomainStore que por sua vez delega a objetos internos que chamam o banco de dados. O repositorio no uma interface, uma implmentao concreta e nica. O objetivo do repositorio encapsular todas as logicas de pesquisa. Ou seja, seus metodos so coisas como obtemProdutosVendiddosNosUltimosMeses(int quantidadeDeMEses): List , obtemClienteQueCompraramOProduto(Produto p), etc ninguem acima do repositorio sabe como feita a pesquisa. O repositorio pode ser implementado de vrias formas, mas a forma escolhida no muda no tempo ( ao contrario do DAO). Se quer usar SQL puro, vc precisa encapsular a escrita do SQL em uma outra camada e fazer o repositorio chamar essa camada. O Repositorio no pode escrever
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 11/14

14/09/13

DAO | Srgio Taborda's Weblog

SQL. Voc precisa usar Query Objects, ou seja precisa de uma forma simplificada isolar o que o critrio de como ele se executa. O repositorio s decide qual o critrio, no como ele executado. O EntityManager um DomainStore, o Session do Hibernate um DomainStore, Os objetos de Criteria do Hibernate so Query Objects e no JPA (2.0) tambm possivel escrever as queries em objetos. A ideia que o repositorio, ao contrario do DAO, no sabe e no quer saber como a pesquisa efeita na realidade, mas eles quer dizer qual a regra. Por exemplo pesquisa na tebela X pelo campo A e encontre todos os elementos em Y cujo campo B igual a A esta a regra de neogico. E isto que fica no repositorio. A regra, no a implementao da execuo. Um criterio como este pode ser executado como um SQL, mas tambm pode ser executado com for em cima de colees, j que o Repositorio no sabe onde as informaes esto de fato. Isso quem sabe o DomainSotre, ou uma camada de DAO. No seu caso parece mais simplesmente implementar o SQL no repositorio, mas isso no a implementao do padro Repositorio, e sim a implementao do padro DAO. Para mais informaes sobre a arquitetura de Repositorio e Query Object leia este artigo 1. No trackbacks yet. Tem de ter a sesso iniciada para publicar um comentrio. Feed RSS

Artigos recentes
O fuso e a roca Voto Consciente A Ecologia, a Sacola e a Cultura

Blog no Java Buinding

Com a inaugurao do JavaBuilding as minhas obervaes sobre desenvolvimento de software em geral e sobre Java e Scrum em particular podem agora ser seguidas no meu novo blog Caderno Srgio Taborda no JavaBuiliding. Este blog permance apenas para assuntos no relacionados a desenvolvimento de software.

Caderno no Javabuilding
Java EE 7 Arquitetura Padro Completa Pacotes, Camadas e Mdulos Otimizao Preventiva Java 8 Preldio O que gil significa Mtricas, Indicadores e Scrum

MiddleHeaven
Javadoc Disponivel Lista de Discusso Seis anos e muito para fazer Seguindo em frente
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 12/14

14/09/13

DAO | Srgio Taborda's Weblog

No cu do meio Novo Conteudo Utilitrios: Colees aumentadas Nosso novo blog MiddleHeaven Pr-Alfa MiddleHeaven Reloaded

Twitter
Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Meta
Registar Iniciar sesso RSS dos artigos Feed RSS dos comentrios. Blog em WordPress.com.

Pginas
Desenvolvimento de Software A Arte de Fabricar Software Arquitetura Arquitetura Orientada ao Domnio Arquitetura Web Java Colees: Como no usar Arrays Do DAO ao Domain Store Excees: Boas Prticas, Ms Prticas Excees: Classes Utilitrias Excees: Conceitos FAQ Primeiro Programa Sorteio aleatrio sem Repetio Trabalhando com Nmeros Igualdade em Java Introspeo java.lang.Object OO Herana Polimorfismo Separao de Responsabilidades e Encapasulamento Os 10 mandamentos do bom programador Java Palavras Reservadas Patterns Adapter Bean Builder Composite DAO Factory Factory Method Fastlane Iterator
sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/ 13/14

14/09/13

DAO | Srgio Taborda's Weblog

Money MoneyBag MVC Query Object Repository Singleton Transfer Object Value Object Scrum Equipe Planejamento Produto e Projeto Projees Sprint Valores Fsica Mecnica Quntica Livros Magic: The Gathering O Segredo do Magic Sobre mim Topo WordPress Blog em WordPress.com. The INove Theme.

sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/

14/14