De onde você tirou “sistemas orientados a dados”?
The JavaServer Faces Managed Bean Facility
A first class Inversion of Control (IoC) Facility for POJOs?
:arrow: Veja na pratica algo relacionado , as colocações do Sergio estão corretas sobre a responsabilidade ao Managed Bean
:arrow: http://www.oracle.com/technology/tech/java/newsletter/articles/jsf_pojo/index.html
[quote=Rubem Azenha][quote=sergiotaborda]
[/quote]
De onde você tirou “sistemas orientados a dados”?[/quote]
é uma expressão para ser comparada com sistemas orientados a dominio. Sendo que o texto é sobre Dados vs Dominio
inevitávelmente tenho que falar em “sistemas orientados a dominio” e “sistemas orientados a dados”.
(sendo que nos texto se define o que é “dados” e o que é “dominio”)
Ta, mas o que eu quero saber é:você inventou essa expressão ou você tirou de algum outro lugar?
[quote=sergiotaborda][quote=Erick Jeronimo]
Qual o objetivo de separar essas operações em um serviço? sendo que para consultas, o ManagedBean pode solicitar diretamente ao repositório? As operações de insert, update e delete não podem ficar diretamente no managed bean? já que este possuiria uma referência ao repositório mesmo…
[/quote]
Normalmente o sistema não fará um save ou delete “puro”. Ou seja, ele vai fazer outras operações. Por exemplo, ele pode enviar emails , informar listeners de eventos, fazer operações de save/delete em cascada, validações , verificação de autorização, log , etc…
No inicio pode parece apenas um save simples no banco, mas à medida que o sistema cresce novas coisas são adicionadas. Se vc não isolar em um serviço o seu ManagedBean vai aumentar em responsabilidade. É esse o problema. Ele não tem , nem deve ter essas responsabilidade. Ele é um item da apresentação. Não deve conter lógicas de negocio. Colocando em um serivo a coisas fica muito mais simples. Um serviço é definido como uma interface e uma ou mais implementações. O que significa que no futuro se vc mudar o serviço o seu JSF não vai nem saber. Esta flexibilidade mostra que as responsabilidades estão bem separadas e isso singifica que é um melhor modelo que meter tudo na mesma classe. [/quote]
Sérgio,
A arquitetura neste caso ficaria: view -> controller -> services -> persistência
isto mesmo?
[quote=Rubem Azenha]
Ta, mas o que eu quero saber é:você inventou essa expressão ou você tirou de algum outro lugar?[/quote]
:arrow: Desenvolvimento Orientado a Dados é o mesmo que domínio entretanto esse visa um aspecto de persistência(por invocação) que à domínio(foco ao objeto de negócio) ao domain logic as features são persistidas instantaneamente.
E o que diabos a gente pode inferir dessa sua resposta? Ele inventou ou não o termo?
Ah, o arquiteto de informação 
[quote=Mauricio de Mello][quote=sergiotaborda]
No inicio pode parece apenas um save simples no banco, mas à medida que o sistema cresce novas coisas são adicionadas. Se vc não isolar em um serviço o seu ManagedBean vai aumentar em responsabilidade. É esse o problema. Ele não tem , nem deve ter essas responsabilidade. Ele é um item da apresentação. Não deve conter lógicas de negocio. Colocando em um serivo a coisas fica muito mais simples. Um serviço é definido como uma interface e uma ou mais implementações. O que significa que no futuro se vc mudar o serviço o seu JSF não vai nem saber. Esta flexibilidade mostra que as responsabilidades estão bem separadas e isso singifica que é um melhor modelo que meter tudo na mesma classe. [/quote]
Sérgio,
A arquitetura neste caso ficaria: view -> controller -> services -> persistência
isto mesmo?[/quote]
Mais ou menos.
view -> controller -> service (singular) -> persistência
O controller só consome um unico serviço. Se a tarefa necessita da invocação de muitos serviços, cria-se um serviço que chama esses outros na sequencia certa. ( Isso é o padrão Service Façade)
O controller não sabe o que vai acontecer ao chamar o serviço. Portanto ele só pode chamar um único serviço.
Se chamar mais do que um, isso automaticamente implica em que o controller sabe demais pois ele conhece a sequencia lógica das chamadas.
[quote=Rubem Azenha][quote=sergiotaborda]
é uma expressão para ser comparada com sistemas orientados a dominio. Sendo que o texto é sobre Dados vs Dominio
inevitávelmente tenho que falar em “sistemas orientados a dominio” e “sistemas orientados a dados”.
(sendo que nos texto se define o que é “dados” e o que é “dominio”)
[/quote]
Ta, mas o que eu quero saber é:você inventou essa expressão ou você tirou de algum outro lugar?[/quote]
E responder a essa pergunta é importante porque … ?
O importante é entender a mensagem do texto. A mensagem é basicamente que: Dominio não são apenas dados. Sistemas que encaram “cliente” , “produto” apenas como dados são antiquados e votados a fracassar. sistemas legados dos anos 80 e alguns dos 90 e alguns de agora, encaram as coisas assim. É por isso que o Banco de Dados é rei e senhor de tudo e as integrações são complexas porque sempre são no nivel dos dados.
Sistemas orientados a dominio são mais flexiveis porque o banco é apenas um repositorio e a integração acontece ao nivel dos serviços.
Por que eu estou curioso para saber se você inventou uma abobrinha sem sentido só para menosprezar quem tem uma opinião diferente ou se você se refere a um conceito bem embasado.
A mensagem do texto é: quem usa DAO não sabe fazer software aplicando DDD, o que é na verdade um tremenda bobagem.
E não é por que eu uso DAO que eu trato as entidades como apenas dados ou faço integração via banco de dados.
Já chegamos a conclusão uma vez aqui neste forum a muito tempo atrás que é perfeitamente possível usar DAO interfaceando um repositório e que na maioria dos casos não fazia sentido criar uma camada a mais de repositório ou expor o mecanismo de persistência no repositorio.
E o que diabos a gente pode inferir dessa sua resposta? Ele inventou ou não o termo?[/quote]
Acho que agente não precisa ser tão religioso contra termos “já ouviu falar em VRaptor Sexy URLs”, então termos são para facilitar uma explicação.
Mudei a assinatura[size=18] ; )[/size]
Bom… Não facilitou.
Bom… Não facilitou.[/quote]
Bom ,não me recordo de alguém dizer se VRaptor Sexy URLs era invencionice ou não, apenas colocaram o termo e ninguém se manifestou, a explicação do Sérgio é coerente e didática, e sobre outro assunto vejo até ligação ao que já estou colocando outras observações indiretas à domínio na questão de Domain Specific Languages no fator “negócios” sobre o uso da melhor tecnologia, algo que é um desenvolvimento orientado a domínio.
[quote=Rubem Azenha][quote=sergiotaborda]
E responder a essa pergunta é importante porque … ?
[/quote]
Por que eu estou curioso para saber se você inventou uma abobrinha sem sentido só para menosprezar quem tem uma opinião diferente ou se você se refere a um conceito bem embasado.
[/quote]
Eu não estou preocupado em embassar conceitos. Nem em basear conceitos. É por isso que se chamam conceitos. Conceitos ou vc tem, ou vc não tem. Podem-se ensinar e podem-se aprender, mas não se podem justificar.
Por exemplo, justifique que 2 é maior que 1.
Simplesmente é.
Se eu quisesses basear os conceitos - ou sei lá o que vc quiz dizer com essa frase - eu escrevia papers e dava palestras. Sendo que é um blog de exposição de ideias o objetivo é cada um ler e tirar suas conclusões.
é uma pena que vc só tenha entendendo isso porque isso nem está no texto. E eu nunca disse isso.
Vc pode usar DAO à vontade. MAs DAO verdadeiro, não esse hibrido metamorfoseado que o pessoal chama de DAO, mas que na realidade é uma camada para chamar o hibernate.
O texto tem um obejtivo muito simples:
[quote=http://sergiotaborda.wordpress.com/2008/10/06/dados-vs-dominio/]
Parece que a diferença entre um sistema orientado ao domínio e um sistema orientado a dados ainda não está bem clara. Isto é um problema importante porque sem a clara diferenciação entre os dois paradigmas não é possível entender e comparar as vantagens e desvantagens de cada um.
(…)
Em um sistema orientado a dados o mais importante é o ciclo de vida dos dados. Criação - Preservação - Procura - Edição/Remoção - Atualização. Normalmente o foco é a Preservação.
(…)
Bom, mas afinal em que a orientação ao domínio é diferente? A primeira coisa é que a orientação ao domínio é, explicitamente, orientada a objetos. O objeto, não os dados, são o principal componente.O objeto, não os dados, são o principal componente. Repare que os dados são 50% de um objeto: o estado. Os outros 50% - o comportamento - eram largamente espalhados pelos sistemas, resultando em código duplicado de difícil manutenção. Era esse o papel das procedures e dos triggers: serem o comportamento dos dados.[/quote]
Se vc não enxerga diferença entre “objeto” e “dado” não é problema meu.
O objetivo do texto é apenas dizer que ha diferença e basear a afirmação de que ha diferença.
O objetivo do texto não é cunha novas palavras ou conceitos.
Eu sei que vc sofre de Sindrome de DAO e já o alertei para o problema. Vc não enxerga além disso. O que eu posso fazer? Um dos sintomas é exatamente achar que não está infetado. Tlv a mesma opinião dita por outras pessoas valha mais. Usar DAO com DDD é palhaçada sim! Confundir DAO com Repository é palhaçada sim!
Eu realmente espero que ao falar que DAO é uma camada para chamar o Hibernate você apenas dado um exemplo e não falado que DAO serve só para Hibernate…
A diferença entre um sistema orientado ao domínio e um sistema orientado a dados ainda não está bem clara por que, pelo que você mostrou, esses dois conceitos foram inventados por você mesmo.
Ok, então vamos usar um termos mais conhecidos e com um embasamento mais forte?
Quando você diz sistemas orientados a dados você quer dizer sistemas com uma arquitetura que usa Transaction Scripts ao invez de Domain Model? Ou simplesmente sistemas que usam DAO? Ou simplesmente sistemas que tenham “VOs” burros?
Eu entendo que uma arquitetura complexa de DAOs não é bom, e você é melhor fazer loja.getProdutosVendidosEm(data) do que lojaDAO.findProdutosVendidosEmData(loja, data), mas o uso de DAO não inviabiliza fazer loja.getProdutosVendidosEm(data). Eu, por exemplo, faria o método loja.getProdutosVendidosEm(data) chamar internamente um DAO (ta, pode ser interfaceado por um repository, já discuti isso uma vez com o Shoes e eu concordei com ele quando ele disse que nomenclatura faz uma grande diferença). Ou você exporia um EntityManager (ou uma Hibernate session, uma JDBC connection, uma FileInputStream, um SocketChannel, uma chamada a um WS) na entity Loja?
Agora, poste alguns exemplos de código de repositórios seus, vamos ver se é muito diferente dos DAOs interfaceando repository
Aliás, Sérgio, agora que eu vi que você linkou o blog do Guilherme Chapiewski, eu já tinha lido esse post na época que ele postou (é um dos blogs que eu “assino” o feed) e acho que você não deve ter lido até o final do mesmo:
(o grifo é meu)
:arrow: (Não é o que diz Martin Fowler) Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers
:arrow: [color=blue](Nota uma observação melhor ainda)[/color]:A Repository is a domain level artifact and mostly corresponds to an Aggregate Root. One repository can be implemented in terms of multiple DAOs. One DAO roughly corresponds to a single table. Hence you can say that a Repository is at a higher level of abstraction than the DAO.