Estou criando uma aplicação e, estou com uma dúvida: é aconselhavel deixar os daos para serem acessados remotamente?
Uma vantagem que eu vejo nisso é que o dao tem condições de ficar em uma vm separada das classes de negocio, desafogando o servidor com as classes de negocio.
Por outro lado posso incentivar um desenvolvedor de acessar diretamente esses daos remotos através de uma view, evitando a camada de negócios.
No caso de usar os daos locais, além de onerar o servidor dos objetos de negocios, no caso de uma outra aplicação alterar dados na base, e o dao utilizar algum framwork orm, a camada de negócio não terá os dados atualizados gerando problemas, mas evito que alguém acesse a camada dao diretamente de uma view.
Então vc vai adicionar uma layer a mais para cada classificação de classes de infraestrtura? Vai ter uma VM para os Services de seu MVC web ou controladores Swing, outra para Gateways de Email/FTP/etc, outra para DAOs, outra para Façades a.k.a. delegates (se os utilizar)além de todos demais serviços que não são domain… e tudo isso vai ser disponível para invocação remota, só para ter uma VM dedicada “apenas” para objetos de negócio?
Pq programação distribuida incentiva o acesso diretamente a estes componentes pela view? não entendi.
OBS: Não que eu ache absurdo acessar um componente distribuído pela view, desde que vc possua um framework que disponibilize isso pra vc de forma transparente (sem ficar fazendo lookup na página).
OBS2: Não que eu ache legal objetos distribuídos.
Não entedi também. O que tem haver ORM ou não com isso? Se a query faz uma consulta vou ter os dados atualizados do mesmo jeito. Se eu faço refresh ou merge tbm. Mas o que mais me deixou sem saber é: o que tem haver o DAO ser distribuído ou não com isso?
DAOs possuem a granularidade para objetos remotos. DAOs expõem dados e não comportamento, logo fica muito difícil evoluir a aplicação, pois não existem contratos, mas trocas de dados. Uma chamada remota é incrivelmente mais cara que manter todas classes e objetos dentro da VM.
Não é nem solução nem armadilha, é um desastre a caminho.
Ter um DAO exposto como serviçonuma rede é basicamente a mesma coisa do que usar Stored procedures ao invés de acessar tavelas diretamente. Até pode ajudar em alumas situaçõs mas causa mais problemas do que evita.
Quando você tem acesso apenas à uma stored procedure ou aos métodos expostos pelo DAO o que voc6e tem é um banco de dados limitado. Ao invés de ter serviços de negócio ou mesmo de ter o poder de um banco relacional o que você tem é uma interface para resgatar dados extremamente (e desnecessariamente) especializada, que vai requerer manutenção constante e possui baixíssima flexibilidade, além de te impedir de usar ferramentas interessantes como JPA/Hibernate.
Você não precisa de um seridor próprio, nem máquina nem servidor de alicações. aliás, para ter serviços por via de regra nem mesmo outra aplicação você precisa. é tudo uma questao de como vc divide seu sistema
[quote=pcalcado][quote=aleck]
separe em um servidor próprio.
[/quote]
Você não precisa de um seridor próprio, nem máquina nem servidor de alicações. aliás, para ter serviços por via de regra nem mesmo outra aplicação você precisa. é tudo uma questao de como vc divide seu sistema[/quote]
Eu mencionei um servidor próprio pois me pareceu que ele quer um sistema distribuido, onde o negocio ficaria separado do acesso aos dados.
[quote=aleck]
Eu mencionei um servidor próprio pois me pareceu que ele quer um sistema distribuido, onde o negocio ficaria separado do acesso aos dados.[/quote]
[quote=aleck][quote=pcalcado][quote=aleck]
separe em um servidor próprio.
[/quote]
Você não precisa de um seridor próprio, nem máquina nem servidor de alicações. aliás, para ter serviços por via de regra nem mesmo outra aplicação você precisa. é tudo uma questao de como vc divide seu sistema[/quote]
Eu mencionei um servidor próprio pois me pareceu que ele quer um sistema distribuido, onde o negocio ficaria separado do acesso aos dados.[/quote]
[quote=pcalcado]
E onde entrariam servicos nessa situacao?[/quote]
Entendo que as aplicações podem ser transformadas em serviços e podem compartilhar suas funcionalidades através destes, apenas dei a ideia de separar os serviços em uma maquina a parte. O unico problema que vejo neste caso é a necessidade de criar os serviços em aplicações separadas, provendo apenas o necessario, mas é perfeitamente possivel.
Como o Lezinho disse, não dá pra decidir algo deste tipo sem mais detalhes, e não é qualquer ambiente que necessita ou suporta tal mudança.
Todo mundo já falou tudo, sendo que a frase do Louds resume a maioria dos pensamentos: Não é nem solução nem armadilha, é um desastre a caminho.
Aliás, para que serve um sistema distribuído? Não vale responder nada que não seja um requisito explicito do negócio.
Como já disse várias vezes, os EJBs anteriores ao 3.0, principalmente aqueles em que tudo era remoto, foram a maior tolice que já vi na área de TI desde que escrevi meu primeiro programinha em 1968.
Além de ser tolice, propiciou a monte de desenvolvedores fazer sistemas distribuídos onde isto não era necessário. Poucas vezes na minha vida vi requisitos de sistema onde distribuir valia a pena e compensava os problemas (custo maior, performance, backup complexo, etc.).
E nas poucas vezes que ficou clara a necessidade de fazer um sistema distribuído, em pelo menos uma delas sei que usaram MDBs para distribuir serviços que por serem independentes podiam ser distribuídos (era um caso grande de billing).