Estou estudando tecnologias para desenvolver um sistema (baseado em swing) em camadas (MVC) distribuído. (ordens he he he )
Pesquisei aqui no fórum e achei tópicos interessantes sobre esse assunto. Mas algumas dúvidas surgiram sobre o que se usar hoje em dia. Segundo a pesquisa, foi discutido e chegado a uma conclusão de separar a Visualisação (No Cliente) do Controle e Modelo (No servidor)… Qual a tecnologia mais interessante na opinião de vocês para usar na comunicação entre a visualização e o controle?
WebServices? Servlets? Outro? Ou seria mais interessante implementar tudo em web?
E na camada de persistência ? Hibernate? JPA? TopLink.?
Fazer um distema MVC distribuído, mas em que sentido? Cada parte da sua aplicação deve rodar em um servidor diferente? Se for o caso deria EJB (use a versão 3.0).
Em relação a persistência recomendo o Hibernate com JPA. Lembrando que o JPA é apenas um conjunto de interfaces para padronizar o acesso a banco. Embaixo dele vc terá que rodar o Hibernate ou Toplink, por exemplo.
Seria uma opção excelente o uso do EJB 3, levando em consideração o uso de um servidor JBoss por exemplo.
Mas no caso do WebService, dependendo de sua utilização faz sentido, mas é necessário entender o que você queria fazer como: negócio do sistema, quem irá acessar o sistema, ou seja, local, em uma mesma rede.
É necessário saber também se outras aplicações utilizaram recursos do seu sistema.
Acho que seria interessante vc colocar tudo isso no papel ou descrever para que seja dada uma arquitetura interessante para o seu projeto…
E quanto a separação do MVC… Pesquisei pela net e qual seria a melhor maneira de separar o sistema ? Tendo em vista que a camada de visão vai ser em swing.
V (no cliente) --------------> C e M (no servidor)?
ou
v e C (no cliente) ---------> M (no servidor)?
ou
v e C e M (no cliente -----> Base de dados (no servidor)?
[quote]V (no cliente) --------------> C e M (no servidor)?
ou
v e C (no cliente) ---------> M (no servidor)?
ou
v e C e M (no cliente -----> Base de dados (no servidor)?[/quote]
Considero a primeira opção mais interessante no seguinte aspecto:
Controle no cliente pode ser um pouco complicado em relação à máquina do usuário. Em um sistema distribuido, pode ter usuário dom Pentium II com 128 de RAM e com DualCore com 4 Gb de RAM. Portanto para evitar que clientes ocm máquinas antigas tenham problema de processamento e memória acho mais interessante concentrar em servidor o processamento. Outro aspecto fundamental a ser observado é a segurança, que dependendo do sistema pode determinar sua escolha.
Não gosto da solução MVC inteiro no cliente…seria a última que eu adotaria…
Não conheço muito de EJB, mas qual seria o papel dele num sistema onde no cliente estaria a camada de Visualização e no servidor estaria a camada de Controle e Modelo? A comunicação entre a visualização e o controle? ou faria a manipulação da persistencia do sistema?
Não sou nenhum especialista em EJB, mas vou tentar explicar o basico
EJB é uma forma de você criar aplicações distribuídas, onde cada pedaço da aplicação (inclusive a camada de modelo) está em um computador, por exemplo.
No caso o EJB é aplicado na camada de modelo (se não me engano). Em relação a persistência não teria relação direta com o EJB, mas sim a elaboração de uma camada de persistência, comforne o padrão de projeto DAO.
Camadas não é relacionado a MVC! E não existe MVC distribuído, apesar de existir camadas entre máquinas diferentes (que aqui, vou chamar de ‘tier’). Cada tier implementa seu próprio MVC. Pra explicar isso, vou mostrar com um exemplo:
Imagine que sua aplicação swing irá se comunicar com um servidor via socket TCP enviando e recebendo XML. O tier do servidor possui objetos que representam o domínio, cujo estado é persistido na base de dados (esses objetos são o model). Nesse tier, existem também objetos que transforma o model em XML (esses objetos são a view). E haverá um código que liga essas duas partes (controller).
O tier do cliente possui objetos que encapsulam o acesso ao servidor (essa parte é o model). Existem também código swing (parte da view) e mais código que liga os dois (controller).
Ou seja, não tem esse negócio de controller de um lado, view do outro… Cada pedaço faz seu MVC.
(E outra coisa, fazer o swing chamar queries do banco direto é um erro! Não cogite essa possibilidade.)
Apenas surgiu uma dúvida quanto a isso. No caso de uma aplicação utilizando JSF simples, sem EJB, como ficaria essa divisão? No caso no cliente continua tendo a camada de visão e apenas de visão certo? E no servidor ficariam apeas a de controle e de modelo?
Aparentemente ficaria dessa forme e portanto não teria no servidor as 3 camadas.
[quote=thiagomont]Leonardo3001, muito interessante essa abordagem.
Apenas surgiu uma dúvida quanto a isso. No caso de uma aplicação utilizando JSF simples, sem EJB, como ficaria essa divisão? No caso no cliente continua tendo a camada de visão e apenas de visão certo? E no servidor ficariam apeas a de controle e de modelo?
Aparentemente ficaria dessa forme e portanto não teria no servidor as 3 camadas.
Esse tópico está ficando interessante…
flw.
[/quote]
O cliente interage com um componente View. É só o que ele vê. Mas as solicitações que ele faz, a partir desse componente View, invocam componentes Controller (em aplicações Web são servlets muitas vezes). Os Controllers implementam alguma lógica que se comunica com o Model e despacham uma solicitação de View a partir das modificações feitas em Model.
Eu acho que independente de tecnologia, MVC é MVC (e nesse caso ainda é o MVC-2, porque o próprio Controller está despachando solicitações da View, ao invés da View observar o Model e se atualizar a partir disso).
E, de qualquer modo, como o Leonardo3001 falou acima, MVC não é 3 camadas:
Pois é…estava pensando em implementar uma interface gráfica como se fosse web, mas só que em swing e fazer se comunicar com o servidor contactando as outros módulos, a parte de controle do sistema… ou seja, toda a transação e processamento seria no servidor, o cliente só ficaria com a interface gráfica e fazendo requisições ao servidor… (um cliente magro, anoréxico he he he) , valeria a pena fazer desta forma? E pelo que a imagem passada pelo fantomas apresenta que esta abordagem é possível com EJB… estou certou ou me enganei?
[quote=leopoldof]Pois é…estava pensando em implementar uma interface gráfica como se fosse web, mas só que em swing e fazer se comunicar com o servidor contactando as outros módulos, a parte de controle do sistema… ou seja, toda a transação e processamento seria no servidor, o cliente só ficaria com a interface gráfica e fazendo requisições ao servidor… (um cliente magro, anoréxico he he he) , valeria a pena fazer desta forma? E pelo que a imagem passada pelo fantomas apresenta que esta abordagem é possível com EJB… estou certou ou me enganei?
Obrigado[/quote]
Bom, se for só pra um cliente Swing se comunicar com um servidor acredito que nem precise de EJB. Nesse tópico foi discutido sobre isso:
Aliás, acho que tem vários outros. Eu não conheço EJB, mas normalmente vejo pessoas falando pra evitá-lo e usar só quando necessário. Tente fazer pelo mais simples.
Olá… Estou fazendo um trabalho de iniciação científica onde um dos assuntos principais é a arquitetura mvc.
Passei por este tópico e achei a discussão muito interessante…
Estou com algumas duvidas com relação á como implementar o componente controller!
[quote]Olá… Estou fazendo um trabalho de iniciação científica onde um dos assuntos principais é a arquitetura mvc.
Passei por este tópico e achei a discussão muito interessante…
Estou com algumas duvidas com relação á como implementar o componente controller!
Gostaria de saber se vcs poderiam me ajudar
bjuus a todos
Obrigada[/quote]
Diga quais são suas dúvidas que lhe ajudaremos.
Recomendo a leitura do livro Head First - Design Patterns e dos artigos:
Obrigada pela ajuda, mas as minhas dúvidas são mais voltadas a implementação do componente de controle.
É que estou na fase de implementação do sistema e estou com algumas duvidas quanto ás classes necessárias para o correto funcionamento do componente de controle. Estou com dificuldades em encontrar esse material na internet.
