DAO remoto: Solução ou armadilha?

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.

Valeu pela foça galera!

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.

Que tipo de problemas você acha que pode gerar? Quando você diz que vai ser igual a stored procedures, o que quer dizer especificamente?

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.

Se você quer precisa de um ambiente distribuido utilize serviços e os separe em um servidor próprio.

Se continuar com sua idéia, daqui um tempo você terá isso: http://en.wikipedia.org/wiki/God_object

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

pcalcado:

aleck:

separe em um servidor próprio.

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

Eu mencionei um servidor próprio pois me pareceu que ele quer um sistema distribuido, onde o negocio ficaria separado do acesso aos dados.

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.

E onde entrariam servicos nessa situacao?

aleck:

pcalcado:

aleck:

separe em um servidor próprio.

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

Eu mencionei um servidor próprio pois me pareceu que ele quer um sistema distribuido, onde o negocio ficaria separado do acesso aos dados.

O ponto esta em saber a real necessidade disso.

pcalcado:

E onde entrariam servicos nessa situacao?

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.

Minha pergunta se deu porque servicos != acesso remoto de dados

Olá

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).

[]s
Luca