DAO's nas classes de negócio

JavaChild Membro desde: 26/09/2008 11:29:03 Mensagens: 108 Offline

pcalcado wrote:

carol_programadora wrote:
Nos no meu "UserRepository" eu tenho algo mais relacionado ao negócio, suponhamos que eu precise de encontrar "Todos usuários com salário > 5.000, que tenham Casa própria quitada, que não tenha filhos, seja solteiro etc etc"(considere que seja uma consulta bem complexa) e lá na interface repository eu terei este método "findUsersBemDeVida();

Até ai ok, pois representa algo bem espefíco, mas agora se eu estiver usando este modelo:

UsuarioRepository > UsuarioDecorator(implements UsuarioRepository) > UsuarioDao

Não entendi, por que você está usando essa hierarquia toda? Que tal uma interface RepositorioUsuarios que é implementada por um UsuárioDAO, uma coisa simples que funciona?

carol_programadora wrote:
Onde ficará meu SQL(HQL seja o que for) dessa consulta?

Na implementação do Repositório, o DAO na minha proposta acima.

Entendi, sua proposta é tirar essa hierarquia. OK.
Mas pensei nessa estrutura apenas pelo detalhe abaixo:

Se nas minhas classes de controller, quando eu preciso de alguma consulta direta, sem ter negócio envolvido, inclua aqui dados brutos para popular comboBox, DataTable... etc eu tinha pensando em injetar uma dependência "UsuarioDao" no meu "UsuarioController" e não um UsuarioRepository... achei que fosse errado colocar uma dependência do repository no controller, achei que elas deveriam ser usada APENAS por classes do domínio, por domínio quero dizer as entities e os services, então eu pensei que o controller não deveria ter esse contato.
Então creio que estou errada, utilizando sua sugestão Shoes, minha única opção pra inserir dentro do "UsuarioController" seria minha "UsuarioRepository.

Shoes, explorando-te um pouco mais

, vendo o projeto ddd-sample, eu vi algo que me deixou confusa:
La está divido assim:
Application
Domain
Interface
Infrastructure

Dentro de Application e Domain, tem pacote "service", pelo que li e entendi até agora(a não ser que fiz bagunça) minhas regras de negócio devem ficar no Domain > Service, certo?!

Fiquei confusa com essa camada "Application", não tinha visto sobre ela no DDD, e na verdade pouco conheço ainda dela no geral(é tanta coisa pra estudar

falta tempo...), mas pesquisando achei essa definição , que menciona na camada de aplicação serviços EJB, JMS... Agora confundi tudo sobre essa application, JMS e EJB não é infra? O certo não seria ela estar na camada de infrastructure, assim o Dao que acessa o banco, eu teria esses serviços de infra? Ou não? Totalmente confusa agora.

Se puder esclarecer o que vai exatamente nessa camada "Application".

Obrigada pela ajuda.

A.L wrote:
Corrija se eu estiver errado, mas no projeto exemplo do site oficial (dddsample) , existe um exemplo dessa situaçao, onde a interface do repositorio fica na camada de domínio, e a implementação, no caso em Hibernate, fica na camada de infra-estrutura/persistencia.

Pois é, olhando esse projeto me veio algumas dúvidas a mais.

This message was edited 1 time. Last update was at 30/12/2009 14:02:08

Carol,

de uma olhada nesse esquema

http://dddsample.sourceforge.net/architecture.html

e no livro diz que

' It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down'

ou seja, a camada de aplicação apenas coordena e delega tarefas dos objetos do domínio.

Ignore essa definição da arquitetura JEE, nesse contexto são assuntos diferentes.

Oi,

carol_programadora wrote:
Se nas minhas classes de controller, quando eu preciso de alguma consulta direta, sem ter negócio envolvido, inclua aqui dados brutos para popular comboBox, DataTable... etc eu tinha pensando em injetar uma dependência "UsuarioDao" no meu "UsuarioController" e não um UsuarioRepository... achei que fosse errado colocar uma dependência do repository no controller, achei que elas deveriam ser usada APENAS por classes do domínio, por domínio quero dizer as entities e os services, então eu pensei que o controller não deveria ter esse contato.
Então creio que estou errada, utilizando sua sugestão Shoes, minha única opção pra inserir dentro do "UsuarioController" seria minha "UsuarioRepository.

Uhm... será que você não está pensando em dados quando devia estar pensando em objetos?

Uma combobox ou algo do tipo não exibe dados isolados, ela exibe propriedades de um objeto. Quando você precisa, digamos, listar todos os estados de um país você não deveria fazer algo como:

Desta forma você está quebrando o encapsulamento do objeto país *e* quebrando oencapsulamento da sua infra-estrutura de persistência.

Eu recomendo fazer assim:

carol_programadora wrote:
Dentro de Application e Domain, tem pacote "service", pelo que li e entendi até agora(a não ser que fiz bagunça) minhas regras de negócio devem ficar no Domain > Service, certo?!

Sim.

carol_programadora wrote:
Fiquei confusa com essa camada "Application", não tinha visto sobre ela no DDD, e na verdade pouco conheço ainda dela no geral

Como o Alexa falou, no Capítulo 4 do Domain-Driven Design existe a definição das Camadas propostas pelo Eric Evans:

DDD, Capítulo IV wrote:
* User Interface (or Presentation Layer): Responsible for showing information to the user and interpreting the user's commands. The external actor might sometimes be another computer system rather than a human user.

* Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

* Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

* Infrastructure Layer: Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.

Os slides do meu workshop de DDD podem ajudar: http://www.slideshare.net/pcalcado/domaindriven-design

Olá Philip, esse tópico teria que virar reliquia em algum museu, poxa! rsrsrs, nunca vi um nivel de discussão ser tão profundo, Entretanto queria aproveitar e erguer novamente o tópico.
Trabalhei com dotnet uns três anos, e algumas práticas de desenvolvimento me inspirei na comunidade java, agora pois tenho quase dois anos que estou trabalhando com a plataforma JAVA, bom chega de conversa e vamos ao assunto. Estive conversanto com meu professor acerca da arquitetura de um projeto que estamos trabalhando um sistema de estoques, segue abaixo as ferramentas tecnologicas, abordagens, padrões..e etc:

PLATAFORMA:
JAVA

LINGUAGEM
JAVA

PARADIGMAS
O.O
MVC

IDE
ECLIPSE

PLUGIN FOR ECLIPSE
JBOSS TOOLS

SGBD:
MYSQL in DEVELOPMENT, POSTGRES in PRODUCTION.

framework's de base e de extensão
JSF SPECIFICATION SUN (RI) - MORRAJA PROJECT,
RICHFACES EXTENSION
PRMEFACES EXTENSION

METODOLOGIA DE DESENVOLVIMENTO EM EQUIPES
XP+SCRUM

SEGUE ABAIXO A ARQUITETURA:

VIEW-> paginas jsp (não to usando facelets)
CONTROLLER -> classes de controle responsaveis pelo roteamento (muitos codifica regras de negocios nessa camada!)
MODEL-> classes de modelo de dados (os famosos JAVABEAN)
BUSINESS -> classes e interfaces de negocios.
DAO -> classes e interfaces de acesso ao SGBD
DAO.CONNECTION -> classes e interfaces responsaveis em entregar uma conexao funcional para o DAO, nessa camada temos um pool implementado manual, embora os servidores de APP façam isso.

Com base nisso, eu como já tinha estudado bastante sobre padrões, conceitos, abordagens, percebi que essa arquitetura parece uam receita de bolo, bastante difundida em "distributed Applications" com uso das ENTERPRISE JAVA BEANS. Poxa, então vem a pergunta, eu SEBASTIAO FIDENCIO, desenvolvedor, dependendo da situação e do cenario vou usar o PARADIGMA O.O, porque me da possibilidade reuso, relacionar melhor o problema com a solução por meio de abstração, logo é mais fácil abstrair algo que denota o mundo real à artefatos que não fazem menor sentido no segmento de negocio e sim com principio tecnologicos, para construir sistemas aproveitando tudo que é de bom na orientação a objetos, e o que nosssos inlustres..professores ensinam, é modelar sistemas onde minhas classes de dominio é composta por atributos e metodos, e como na prática aplico a arquitetura mencionada anteriormente? Como a maioria dos desenvolvedores tendenciaram a tal prática?

muitos dizem: !ahh mais o framework JSF funciona dessa forma, portanto o meu modelo de classes tem que se adequar ao framework, onde crio minhas classes de modelo com getters e setters, um construtor vazio..e atributos, para preservar o encapsulamento, poxa mais cadê meus métodos de negocio? está separado? O.O não veio para abstrair a complexidade que tinha de modelar sistemas de forma estruturada, onde a mesma em todas fases e ciclos detona o domino do problema? Ou teriamos um corpo sem vida?

O que vejo é que criou se uma nova abordagem chamada DDD. Domain Driven Design, Desenvolvimento dirigido ao ao dominio, é complexo entender isso? eu acho que não. Tudo se resume na prostituição que os padrões J2EE causaram.,. TO's, V'os.. tudo isso pra atender uma especificação. e na verdade o uso dessas classes de dados separadas das classes de negocio eram aplicadas em aplicações N-TIER, porque tendenciou em usar isso até em aplicações N-Layer?

Acho que DDD é uma forma que o Evans encontrou de Mostrar para os desenvolvedores que Orientação Objetos não foi inspirada em padrões J2EE, e que as EJB's que tentaram se inspirar em O.O e acabou fazendo com que novos analistas e desenvolvedores que surgem a cada dia, aprendem já de forma errada o conceito de O.O. acho que um new(); ou usar um pattern Delegate não denota O.O, mas sim como os objetos usando a inteligencia que está encapsulada em cada um deles interage para realizar os casos de uso.

Se eu seguir a mesma arquitetura que estou seguindo para um projeto em Ruby on Rails ? E eu duvido se não já tem gente por ai,.levando esses costumes mal aprendidos para outras plataformas, eu vim do .NET e conheço N-sistemas que são desenvolvidos dessa forma.

Essa arquitetura acima está ou não totalmente O.O?

Seria correto eu elimiar essa camada de negocio..que pra mim invalida todo conceito de O.O e colocar minhas regras de negocio junto com meus atributos numa mesma classes? ou seja, eu teria a classe Produto.java, 'nada de BO, VO, e tal'. e dentro dela ficasse todas regras de negocio, dai sim apartir dela eu chamaria meus DAO's, se fosse o caso, mas poderiamos ser mais coerente colocando um repositorio como fronteira para a camada de persistencia, e uma facade/service como fronteira em direcao aos meus controles e portanto minhas VIEW'???. funcionaria? seria correto eu setar meus componentes GUI..input direto em cada atributo do modelo, a saber que eu iria chamar um metodo gravar e tal metodo estaria na mesma classe onde setei o atributo do input. Então posso fazer isso? ou irei ferir os principios basicos de um JAVABEAN?

O Modelo fica igual bola de basquete..pra cima e pra baixo..um hora ta na VIEW outra hora está persistido!. Mais parece com uma Entidade do banco de dados que À um objeto que deveria prover serviços para quem o chama.

Imagine o objeto carro sem seus seus comportamentos? Eu não consigo nem imaginar ou abstrair a existencia de um carro com comportamento separado de suas caracteristicas, seria um fantasma? Pelo que sei cada objeto possui identidade unica,e nem precisa o Evans dizer isso. porque é notorio e vem desde o principio.

Dai alguem me disse: Bom faz assim "conforme citado acima a arquitetura" que fica mais organizado, facil manutenção, dai eu disse: Poxa mais e o que o Martim Flower disse acerca do Anemic Domain Model,

então ele disse: !ahhh as ideias do Flower meio confusa, não dá pra confiar.

Att
fidencio

Debugger Membro desde: 04/06/2004 09:58:06 Mensagens: 51 Offline

SEBASTIÃO, eis a minha opinião:

Nossas classes são a "receita" para se construir objetos de um determinado tipo. Objetos que materializam a mesma classe tem o mesmo conjunto de propriedades e métodos. As classes definem propriedades e métodos justamente porque nossos objetos deveriam refletir "indivíduos" do mundo real e consequentemente possuir estado e comportamento.

Agora um exercício de abstração:

Com aquela arquitetura-padrão-j2ee-n-layer pretendia-se antender a uma necessidade de sistemas distribuidos... Compartilhar o estado dos objetos entre máquinas diferentes.

Forçando bastante esse exercício de abstração, pode-se dizer que a união de várias classes-java em camadas diferentes formava uma classe-de-negócio. Por exemplo (simplificado): o conceito Cliente podia ser reproduzido pelo conjunto ClienteBO-ClienteDTO. Eu particularmente nunca gostei disso, mas nem considero uma heresia muito grande, desde que você tenha isso bem claro em mente durante a modelagem.

Essa forma de desenhar sistemas foi absurdamente vulgarizada. É como se houvesse uma solução de caixinha assim: ColoqueONomeDoCasoDeUsoAquiDAO, ColoqueONomeDoCasoDeUsoAquiBO, ColoqueONomeDoCasoDeUsoAquiFacade... Onde você só precisava substituir ColoqueONomeDoCasoDeUsoAqui por Cliente, ou Usuário, ou Projeto, ou qualquer substantivo nascido dos seus requisitos. Desde que você fizesse uma classe de cada camada para cada substantivo, você seria um cara de vanguarda, desenvolvendo soluções OO, portáveis, J2EE, absurdamente escaláveis. Seria convidado para dar palestrar em Nova York e Oslo, e por aí vai.

O grande mérito do DDD, na minha opinião, foi provocar uma "guinada filosófica", do tipo: "Eu fui contratado para usar J2EE, ou para resolver um problema da melhor forma que eu conseguir?". Modificou-se o paradigma. Ao invés de se pensar em como resolver o problema que você ainda nem conhece, agora entende-se e modela-se todo o ambiente que envolve o problema antes de se preocupar com questões meramente computacionais.

Quando vocês se desvinvula daquele "Padrão J2EE" você percebe que existem alternativas simples e naturais para resolver as questões computacionais. Por exemplo... As pessoas simplesmente existem no mundo, o mundo não serializa elas em um banco de dados enquanto elas dormem (pelo menos eu acho que não, fiquei bolado agora...). A necessidade de se persistir de alguma forma as pessoas não é natural, mas é bem clara em um modelo computacional. Definiu-se o padrão Repositório, que ajuda a abstrair esse pequeno entrave, fazendo com que lidar com pessoas seja o mais natural possível. A pessoa simplesmente está lá, não interessa ao cerne do problema como elas estão, desde que estejam.

Acho que você não deve, mas até pode usar a modelagem "Padrão J2EE", desde que seja um ninja da capacidade de abstração.

Se você for um cara normal que nem eu, compre o livro de DDD Evans, o de padrões do Fowler... Estude para caramba. Se você for mesmo normal como eu, a cada vez que você olhar o código, vai identificar uma coisinha que deveria fazer diferente... Por isso você deveria comprar logo o livro de Refactory do Fowler. A partir de um determinando momento o desenvolvimento será natural.

Não acho que seja fundamental seguir o Evans. Acho que o importantíssimo é entender que somos desenvolvedores de software, entendemos de computador e temos que nos esforçar para entender ao máximo o ambiente no qual o nosso produto está inserido. Feito isso devemos nos dar ao direito de refletir, discutir, inventar... que é a parte mais legal do nosso trabalho. Não se preocupe com o que é certo ou errado, tente conhecer todos os pontos de vista, e alinhe-se àquilo que te parece mais simples e natural (no meu caso o que pareceu ser mais simples e natural está descrito no livro do Evans).

Seria correto eu elimiar essa camada de negocio..que pra mim invalida todo conceito de O.O e colocar minhas regras de negocio junto com meus atributos numa mesma classes? ou seja, eu teria a classe...

Com certeza seria correto, mas várias outras coisas seriam corretas... Estude todas elas para embasar sua opinião, desde que depois você junte estado e comportamento dos elementos do seu domínio naa suas classes de domínio. Use repositórios e não deixe vazar absolutamente nadinha da sua infra de persistência para a camada de domínio, nada significa nada mesmo (nem querys, nem exceptions, nem nada). Agregue suas classes de domínio, e respeite essas agregações, por mais que doa às vezes, há uma razão de ser... e use sempre protetor solar!

Abraço

Notícias, artigos e o maior fórum brasileiro sobre Java