MVC...muitas duvidas!

Programação Arquitetura
#1

Pessoal…quero muuuuito e preciso aprender a trabalhar em mvc…mais ou menos tenho uma ideia do que seja:
Ok…mvc(model, view, controller)…
Bom vamos dizer assim:

Se eu criar uma aplicacao onde o usuario cadastra ordens de servico para os clientes…
tenho 3 objetos: usuario, os, cliente ok?
entaum vejamos:
eu vou precisar de uma classe para conectar ao banco de dados: Conexao.
e vou precisar de varios forms para cadastrar cliente, cadastrar user, abrir os, listar os…enfim.
eu devo criar uma classe dao para cada objeto: por exemplo clientedao, osdao, usuariodao?
e a interface? frmcliente, frmusuario, frmos, frmconsulta???
Voces podem me dar uma luz???

E onde fica o servidor de aplicacao nisso tudo…segundo uma conversa que eu tive com um colega…‘basta criar o appserv e os objetos o banco naum importa, a interface naum importa’…naum sei se eu estou sonhando, mas isso eh possivel ?

Obrigada galera []'s

#2

Nos DAO vc deixa a tua logica para manipular os dados, como os metodos para procurar, salvar e remover registros. Os teus forms sao as views, que populam os objetos e delegam para os dao’s a tarefa de fazer alguma coisa com eles.

A tua classe de conexao deveria ser um connection pool, acessivel de qualquer lugar, assim vc consegue pegar uma conexao facil e nao precisa ter que ficar criando o objeto a todo instante.

O uso do servidor de aplicacoes depende… vc pode usar os servicos dele para conseguir uma conexao ao banco, por exemplo… Se nao usar EJB, pelo menos por parte do app server, nao tera mta “magica”.

Rafael

#3

Diana,

Acho que você está fazendo uma salada aqui.

Primeiro, vcoê rpecisa conhecer um pouco de análise OO, aí você vai ter suas entidades e tal.

Aí, você parte para o projeto, onde vai definir os mecanismos que regem sua aplicação.

A questão do AS, é o seguinte: sua lógica de negócios tem que estar isolada em em algum lugar. Não necessariamente num AS, pode ser até numa aplicação Swing.

Se sua lógica estiver contida no AS, você deve fazer a itnerface [seja ela um servlet, um aplicativo swing, webservices, qualquer coisa] utilizar a regra de negócio dentro do AS. O que seu amigo deve ter tentado dizer é que pouco importa para o AS, para a regra de negócio, a interface ser Swing, HTML, XML… ele fica inalterado.

Quanto ao Banco, as pessoas têm que começar a perceber que persistência faz tanto parte do sistema quanto se sua conexão é TCP ou UDP, ou PQP :wink: . Nos tempos antigos da análise essencial]estruturada, as entidades eram modeladas nos bancos de dados proque estes ofereciam mais poder de maneira mais fácil que a própria linguagem para relacionar estruturas de dados. Nosso modelo relacional não consegue se comprotar desta forma com estruturas de dados que envolvem objetos, por isso o banco de dados fica em segundo plano.

Resumindo este ponto: é o banco que se molda à aplicação, não o cotnrário, por isso tanto faz o SGBD usado para a regra de negócio, você vai ter alguma liberdade de usar o banco X porque é barato/seguro/estável/rápido/sei lá, não precisa mais escolher semrpe o banco X porque seu desenvolvedor só sabe XYZ/SQL, ou porque a linguagem de Stored Procedures dos outros bancos são muito ruins…você não irá mais usar StoredPRocedures com tanta frequência [se é que vai suar…].

Quanto ao MVC pura e simplesmente, dê uma lida em:
Beyond MVC: A New Look at the Servlet Infrastructure

Struts, an open-source MVC implementation

Você ahca centenas de textos no Google :wink: um texto legal também tem no COre Java I, quando fala de Swing.

Mas eu tenho certeza que sua dificuldade não é especificamente com este modelo, mas sim com o modelo de camadas. Dê uma lida em algum material sobre arquitetura multi camadas.

[]s

#4

O jeito mais facil que eu consegui usar pra explicar MVC ate hoje é o seguinte:

Imagine que voce esta numa guerra com o webdesigner e com o DBA - o que nao eh nada raro - e ambos querem tirar o seu emprego o mais rapido possivel, te esquartejar e jogar os seus restos pros cães comerem. Pra piorar, eles sao bons no que fazem, entao o chefão tb gosta deles. Ou seja, voce esta numa sinuca.

Entao, o que vc faz? Voce isola o mááááximo possivel o seu trabalho (Controller) do trabalho do designer (View), e do DBA (Model) tambem. Assim, quando o designer resolver trocar todo o layout do projeto, voce nao se afeta. Idem para o DBA: se ele resolver passar algumas madrugadas trocando todo o banco de dados de lugar, voce nao vai ter que mexer em quase nada.

Se voce conseguir desenvolver um codigo assim, pronto, voce esta fazendo seu MVC direitinho. É extremamente importante entrar nesse clima de guerra, mesmo que ele nao exista, se vc quer “praticar” o MVC ate pegar o jeitao da coisa. Depois, com experiencia, voce vence o medinho e a coisa se torna tao natural que vc nao percebe mais que esta fazendo :smiley:

#5

entaum acho que pegay a ideia do mvc…com o que estava tentando fazer antes…

Vamos por partes como diria o esquartejador…
Bom…primeiro eu tenho que entender/praticar bem o conceito de mvc, certo?
para depois incluir um appserv e hibernate para tornar minha aplicacao mais independente de programacao…para que eu naum precise ficar o tempo todo modificando mil detalhes!!!
Tah…entaum recapitulando.:
Os forms sao as view’s
os dao sao as regras de negocio - o controller…
e os objetos e o conexao sao o model…
eh isto???

#6

NAAAAAAO!

DAO eh Data Access Object. Ele serve so como ponte entre o seu modelo de objetos (onde fica mesmo a regra de negocios) e o banco de dados. De uma lida nesse topico, tambem: http://www.guj.com.br/forum/viewtopic.php?t=11147

#7