Morte do Client/Server?

Errr, hmmm. Ficou meio estranho este lance de “modo desconectado” mesmo. O que eu quis dizer foi: será que, em um ambiente em que uma aplicação bem simples (CRUD) que não vai ter acesso à rede (por questões meramente técnicas, como mostrado no exemplo que eu descrevi no tópico antigo), é preciso implementá-la segundo uma arquitetura altamente distribuída (com n-camadas, etc etc etc)? Às vezes isso me cheira a over-engineering.

A locadora die Pirarora do Centro Oeste não tem Internet. Lá eles gerenciam um acervo de 500 itens e 5000 usuários 9só tem uma locadora em toda a região de Zubambeira do Sul).

Ela não precisa de Camadas Físicas nem de servidores, ele precisa de um CRUD.

Realmente este cara não precisa mais que 5-7 classes de domínio, meia dúzia de DAO e um JavaDB.

Se a aplicação for bem construída ele consegue escalar pegando todo o domínio e colocando num servidor, tornando chamadas locais remotas, hoje em dia isso é bem fácil.

Mas tem um ponto nisso aí. A arquitetura original do CRUD não é Cliente/Servidor, a base de dados e a parte lógica é local. Se houvesse um servidor de bases de dados, não faria sentido ter C/S clássico com ele.

–

Acho que o ponto é definir o que seria C/S. Vamos convencionar que estamos falando de aplicações onde existe lógica no cliente que acessa uma base de dados (apenas dados, se tem lógica no SGBD virou servidor de aplicações).

O cenário acima é injustificável? Acho que sim, não consigo pensar em algum meio disso não ser defasado.

A propósito, estou trabalhando num sistema atualmente de venda de passagens de ferrovias. Bom, temos estações em tudo quanto é lugar do norte do país e todas elas têm internet, mesmo que discada.

Olá

Exatamente. E isto não é nenhuma novidade. Em 1997 a Microsoft já pregava a morte da arquitetura C/S quando lançou o Windows DNA baseado em objetos COM e DCOM. Acho até estranho falar deste assunto hoje em dia.

[]s
Luca

Sim, é verdade. Mas a grande pergunta é se precisa.

Nem todo sistema precisa ser multi camada. Muitos sistemas precisam somente acessar um banco de dados na rede local.

Fazer um sistema multi-camadas é melhor, tecnicamente falando, mas é mais caro, mas complicado.

E nesse mercado que o rails (no caso web <-> banco de dados) e .Net matam a pau no Java… mas é principalmente por causa de da cultura Java do que "tecnológica" (não que essa não exista tmb).

Cliente se conectando direto no SGBD indica que dados são compartilhados. Neste cenário utilizar um SGBD como ponto principal de integração é perigoso e não compensa, creio.

Com a facilidade em criar webservices, chamadas RMI, burlap, hessian e etc. não vejo porque fazer isso ao invés de utilizar clientes magros e um servidor.

Como ?
Alguém tem um exemplo ?

Mas com um sistema em plataforma Web, a necessidade de um mediador (camada física) entre a visualização e os dados é menor, pelo menos na minha opinião.
Ai vai a minha pergunt: O que justifica eu ter que acessar objetos distribuidos em uma aplicação Web ?
Load Balance, Cluster ?

Na pior das hipóteses com um Session bean.

Objetos distribuídos são úteis se você tem componentes em máquinas diferentes se comunicando. Hoje em dia o mais sensato é passar dados, não objetos, mas isso pode mudar em breve…

E quando vc fala passar dados vc se refere aos VO’s ?
:lol: