Tecnologias a utilizar em sistema com MVC

Blz?

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.

Espero ter ajudado.

Olá thiagomont… obrigado pela ajuda…não tinha pensado no EJB ainda…vou dar uma pesquisada sobre essa tecnologia…para ver como funciona…

Na verdade estava pensando em usar em duas partes… a parte de visualização no cliente… e a parte de modelo e controle em um servidor…

Dessa forma seria válido usar ejb?

E quanto ao uso de webservices seria válido sua utilização neste caso?

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…

Flw. qualquer coisa estamos ai… fui

Inicialmente o sistema iria ficar operando numa mesma rede

Obrigado

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

Blz?

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

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…

Espero ter ajudado…
flw

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?

…Ou seria mais para Controlar a seção de quem está conectado ao servidor?

Blz?

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.

flw…

O esquema que consta na imagem (sem EJB) é mais simples.

2008/11/10/369cc43ff56a11ff7f4dadc9a787c704_40271.jpg779×592 41.1 KB

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

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.

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.

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:

http://fragmental.com.br/wiki/index.php?title=MVC_e_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?

Obrigado

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

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:

http://www.guj.com.br/posts/list/105351.java

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.

Abraço.

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

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

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.

Obrigada pela ajuda novamente

Até mais.

leopoldof:

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

Já começa mal… .oO(será que é tão dificil de entender que MVC não é separação em camadas ?! )

MVC não é separação em camadas. A visualização o controle o modelo estão todos no cliente. o servidor tem seu proprio modelo, controle e visualização.

com Swing distribuído vc pode usar JNLP (Java Web Start) para distribuir o cliente
o cliente pode comunicar com o servidor via HTTP. HTTP é bom porque atravesssa firewalls, mas vc pode usar outro protolo
se o sistema funcionar em uma rede interna.

O sistema tem vários andares : visualização (swing = muitos listeners, implementação de componentes proprios ,etc… )
Sistema de controle, aqui é uma classe normal que é invocada pelo swing (provavelmente em outroa thread).
Essa classe invocará serviços remotos do servidor.

O servidor acata os pedidos remotos , processa e responde. EJB é uma boa para isto, mas um simples Servlet com controle transacional tb funciona ( tlv não tão escalável, mas … )
Básciamente vc cria um objeto, serializa, manda para o outro lado, desserializa e processa. Se serializa em RMI, HTTP ou JMS não importa muito.

Se vc precisar que o servidor chame funções no cliente, use JMS.

Vc pode usar webservices tb, mas ai se o servidor precisa chamar o cliente ele precisa rodar um servidor HTTP para receber as chamadas. Neste caso pode usar o Jetty. O protocolo de webservice é bom que vc crie o seu. Use REST em vez de SOAP se for por este caminho.

Outra coisa que vc vai precisar é um cache no cliente. Sem ele é impossivel ter algo que funcione.
uma boa divisão de camada ajuda. O uso de serviços e repositorios com domainstores locais e sincronizados (JGroups, JXTA) tb ajuda muito. Aqui vc pode usar algo na linha do Prevayler ou do Space4J mas como “memoria cache” . Outra opção é usar banco embutidos apenas em memoria como o HSQL.

Hibernate só funciona no servidor. no cliente vc não vai poder usar, a menos que o servidor tenha comuniação directa com o banco, o que é uma porcaria de arquitetura …

É obvio que web é mais facil. So o fato de não ter cache de dados já poupa um monte de trabalho.
Se vc preciar integragir com hardware no cliente é melhor swing, mas depende muito do projeto real…

Diga quais são suas dúvidas que lhe ajudaremos.

Recomendo a leitura do livro Head First - Design Patterns e dos artigos:

http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Gostaria de saber se vc tem algum exemplo de código do componente de controle para me passar para que eu possa analisar e ter um exemplo para implementar o meu.

Obrigada desde ja

Abraços

patty.cefetsjbv:

Diga quais são suas dúvidas que lhe ajudaremos.

Recomendo a leitura do livro Head First - Design Patterns e dos artigos:

http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

Gostaria de saber se vc tem algum exemplo de código do componente de controle para me passar para que eu possa analisar e ter um exemplo para implementar o meu.

Obrigada desde ja

Abraços

Não existe um código fixo para o componente controller. As aplicações diferem umas das outras, e as vezes o componente fica bem diferente. O importante é compreender o conceito e saber que o que vc está fazendo é adequado. Mas, eu já vi várias discussões a esse respeito aqui no GUJ. Uma delas é essa:

http://www.guj.com.br/posts/list/73765.java

De qualquer modo, dependendo do que vc vai fazer e também de que tipo de aplicação (Web, Desktop usando Swing, etc.) isso muda bastante. No livro citado anteriormente (Head First: Design Patterns), ao final, tem uma boa explicação sobre isso. Sugiro que se for lê-lo, ao menos leia os padrões que ele referencia no MVC (Composite, Strategy e Observer).

Abraço.

Mais um que pego falando que não é camadas. Camarada, Model é layer, View é layer, Controller é layer. São três layers. Claro que, no Brasil, chamam camadas lógicas (layers) de camadas e camadas físicas (tier) de camadas.
Agora, quer o link da SUN também ou sabe pesquisar?

PS: Nem estou discutindo o que ela disse, apenas evitando que essa loucura do GUJ de falar que o MVC Model 2, usado em Java, não são consideradas layers e que, meu Deus, são uma coisa qualquer por ai.

Sim, é possível com Ejbs e SEM Ejbs também (apresentado na imagem). Para implementações SEM Ejbs indico o framework Spring.

flws

Fala prá nós como é o sistema. É web? É do tipo client x server, ou o quê?

Fala um pouquinho mais sobre seu sistema, talvez alguém possa ter uma idéia prá te passar.

flws

Esse questionamento começou a partir da disseminação do artigo escrito pelo Phillip Calçado: MVC e camadas. Muito bem embasado, por sinal.
Se a gente pegar a tradicional arquitetura multi-camadas ( estou falando de layers, e não tiers ), com apresentação, negócios e persistência, e tentar cruzar com o MVC, percebemos que a view e o controle se encaixam na camada de apresentação, enquanto o model, que representa o estado da aplicação, é o resto ( negócios e persistência ).