Mvc

Pessoal,

Estou com algumas dúvidas na hora de dividir na prática a minha aplicação. 

Levando em consideração uma aplicação web, observem:

View => Minha interface com o usuário

Controller => O cara que serve que leva a informação do usuário para o model e vice-versa.

Model => Regras de negócio e persistência

Esta primeira parte está correta ?

Bom então vamos ao prático:

Numa aplicação web utilizando struts:

Views => minhas páginas JSP

Controller => o servlet do struts

Model => As minhas Actions e ActionForms(Regras de negócio), meus beans e meus DAOS (Persitência)

Isso está correto ?

Alguns desenvolvedores defendem que as regras de negócio não deveriam ficar dentro dos Actions/ActionForms. Onde ficariam ?

No contexto acima qual é a forma mais elegante de se dividir a aplicação ?

Obrigado Pessoal

E com razão pois, suas actions são controladores, ou pelo menos deveriam ser…

tu pode usar uma classe intermediaria entre controle e persistencia para tratar sua lógica de negócios, ou seja, na camada de modelo temos varias subcamadas digamos assim, as quais compoem o mesmo…entre elas a persistencia…

[]'s

Suas Actions fazem parte do Controller. O Struts (aliás, procure outro framework) é um framework, isso quer dizer que ele deve ser extendido. No caso você extende o controller do Struts com seus controllers (suas actions).

As regras de negócio ficam nos objetos de negócio. Mais detalhes Mundo Java #15 e #17.

Sou novo no GUJ mas já estou me habituando a escrever logo após ao pcalcado.

Só para aproveitar a deixa dele, um bom framework para aplicações MVC para web é o Spring MVC.

Ah, e se você está escrevendo toda a sua regra de negócio nas classes Action/ActionForm tome cuidado. Você está deixando seu código muito dependente do framework. De repente você quer trocar de framework (por algum motivo qualquer) e todo o código realmente seu (a lógica da sua aplicação) estará preso ao framework.

Abraços

Certo… era justamente isso que estava precisando entender. Isso que vocês me falaram batem com uns artigos que ando lendo. Na verdade as actions são controllers, elas são como auxiliares do servlet do struts. Pelo que li, elas são uma implementação do padrão Command.

Agora vamos supor que eu tenha uma entidade chamada cliente. Nesta entidade eu tenho as seguintes colunas: identificacao, nome e pessoa. Suponha ainda, que o campo pessoa irá receber JURIDICO se a identificação for um CNPJ e FISICO se na identificação for informado um CPF. Bom, isso é uma regra, certo ?

Pelo o que ando lendo e pelo que eu ando aprendendo trocando idéias com a galera aqui no GUJ, a minha distribuição ficaria assim:

MODELO

ClienteBean = Classe sem validações, sem regas somente com os atributos getters e setters.

ClienteDAO = Classe sem validações , sem regras responsável por pegar o ClienteBean e persistí-lo no banco.

ClienteNegocio = Classe sem os atributos da entidade. Deve conter somente métodos que representem as regras. No nosso caso ele teria o método: public void verificaPessoa(ClienteBean cliente) . SIMPLORIAMENTE FALANDO, esse método verificaria, através do tamanho do conteúdo da propriedade identificacao, o conteúdo do atributo pessoa. Se identificacao tiver 11 caracteres(CPF) , pessoa = FISICA, senão pessoa=JURIDICA .

CONTROLLER

No controller eu teria o servlet do struts(estou estudando vraptor, mas continuo aceitando sugestões)

AdicionaClienteAction AdicionaClienteForm = Cria e popula o bean, submete aos métodos da classe de negócio, e entrega o bean ao DAO para ser gravado no banco.

VIEW

Minha página cadastro-cliente.jsp

O que acham, está legal isso ?
Obviamente não influi no funcionamento , mas a nomenclatura está bacanal ? É assim mais ou menos assim que vocês utilizam ?

Valeu rapazeada !
Mais uma vez obrigado.

Pra que essa separação do ClienteBean e do ClienteNegocio? Não faz sentido ter essas duas classes. Por que não ter uma classe cliente com os atributos e métodos relativos ao comportamento de um cliente?

Ter uma classe apenas com atributos, getters e setters não é uma boa prática. Você está criando objetos burros.

David, não concordo com sua afirmação sobre “objetos burros”, conhecidos value objets.

  • E quando temos um ambiente com a regra de negócio remota, como transitar seus dados/entidades entre eles?

Acho uma pior prática, trabalhar com objetos de negócio dentro dos teus requests para fazer a camada view em tags.

Isso sim fica feio… Hehe…

Até mais…

nbluis, no post acima eu coloquei um link para um artigo que explica o que são objetos burros. Já que você falou em “VO”, coloco agora um outro: Evitando VOs e BOs. Saiba que esse tipo de prática que você está defendendo não é muito OO não…

Como vai David…

Você está falando então que ficaria melhor estruturada, do ponto de vista O.O. se eu juntasse a minha classe ClienteBean com a ClienteNegocio e tivesse simplesmente uma classe Cliente ? Pelo que eu li, a principal tarefa do JavaBean é transportar a informação entre as várias camadas da aplicação, e que por isso não seria desejável que ela fosse carregada de outras coisas. 

Como fica isso com relação a performace se os meus beans tiverem toda a regra de negócio junto ?

Obrigado.

Eu tenho uma concepção parecida com a do amigo maazevedo… Fico imaginando o custo a mais de ter uma única classe que una as características de um JavaBean e de uma classe de negócios… Esses objetos vão ficar transitando do banco (através dos DAOs ou coisa do tipo) até chegar à camada de apresentação, onde tudo o que eu preciso são dos atributos e nada mais… Mas na verdade conterão trocentos métodos que neste ponto serão inúteis pra mim. Como fica o custo desperdiçado de se criar estes objetos?

Depende. Você vai transmitir estes beans via rede? Vão ficar só em memória? Qual a estimativa de quantidade de beans que sua aplicação deve manter instanciados simultaneamente? Qual é a restrição de desempenho que você tem?

Criar soluções mirabolantes baseadas num problema que sequer sabe-se que existe é um dos maiores erros. Na dúvida, siga a linha: “Make it work. Make it right. Make it fast.”

[quote=s4nchez][quote=maazevedo]
Como fica isso com relação a performace se os meus beans tiverem toda a regra de negócio junto ?
[/quote]

Depende. Você vai transmitir estes beans via rede? Vão ficar só em memória? Qual a estimativa de quantidade de beans que sua aplicação deve manter instanciados simultaneamente? Qual é a restrição de desempenho que você tem?

Criar soluções mirabolantes baseadas num problema que sequer sabe-se que existe é um dos maiores erros. Na dúvida, siga a linha: “Make it work. Make it right. Make it fast.”[/quote]

Mas e quanto a escalabilidade? Eu posso não ter problemas com desempenho hoje e o fato de ter classes “mais gordas” não interferir, mas amanhã o volume de acesso da minha aplicação pode dobrar e o que não era problema pode passar a ser…
Da mesma forma, hoje eu posso manter meus beans só na memória, mas amanhã posso querer que essa aplicação envie os objetos pela rede e a coisa toda forme um gargalo… terei reescrever a coisa toda?

Seguindo a linha de raciocínio de que os beans devem possuir os métodos que cuidam das regras de negócio, não fica muito claro pra mim como esse tipo de problema pode ser solucionado (ou até msmo previsto)…

[quote=cassio][quote=s4nchez][quote=maazevedo]
Como fica isso com relação a performace se os meus beans tiverem toda a regra de negócio junto ?
[/quote]

Depende. Você vai transmitir estes beans via rede? Vão ficar só em memória? Qual a estimativa de quantidade de beans que sua aplicação deve manter instanciados simultaneamente? Qual é a restrição de desempenho que você tem?

Criar soluções mirabolantes baseadas num problema que sequer sabe-se que existe é um dos maiores erros. Na dúvida, siga a linha: “Make it work. Make it right. Make it fast.”[/quote]

Mas e quanto a escalabilidade? Eu posso não ter problemas com desempenho hoje e o fato de ter classes “mais gordas” não interferir, mas amanhã o volume de acesso da minha aplicação pode dobrar e o que não era problema pode passar a ser…
Da mesma forma, hoje eu posso manter meus beans só na memória, mas amanhã posso querer que essa aplicação envie os objetos pela rede e a coisa toda forme um gargalo… terei reescrever a coisa toda?

Seguindo a linha de raciocínio de que os beans devem possuir os métodos que cuidam das regras de negócio, não fica muito claro pra mim como esse tipo de problema pode ser solucionado (ou até msmo previsto)…[/quote]

Este aumento no volume de acesso já é algo previsto? Se for, estabeleça parâmetros concretos, faça os devidos testes e então decida se vale a pena implementar assim ou não. Se isso não é um problema agora, por que complicar?

Quanto ao gargalo, dificilmente você terá que reescrever a aplicação toda. Pense que pode ser bem mais fácil você modificar uma parte conhecida e testada partindo de um problema real, do que tentar criar algo novo para um provável problema.

Pessoal,

Eu não sabia que este assunto era tão polêmico. A OO defende que dados e comportamentos relacionados estejam juntos. PORÉM, muitos livros e muitos cursos de java pra internet pregam JavaBeans e Classes de negócio separados.

E ainda tem mais uma - A persistência - onde fica ???

Se os livrosque pregam que Dados e Negocio devem ficar separados (nunca li um assim, ainda bem) falam que isso é OO eles estão errados. E qual o problema com a persistência? Não vejo nenhuma diferença.

Olá,

Duas perguntas…

Primeiro: Voce acha mesmo que esse seria o maior problema pra escalabilidade se seu sistema dobrar a quantidade de acesso?

Segundo: Voce ja serializou uma massa de objetos com todos atributos, metodos, etc dentro dele e outro DTO pra ver realmente a diferenca de tamanho deles?

]['s

Acredito que esses livros que tu fala estejam falando de sistemas usando EJB e/ou sistemas de servico com acesso remoto onde a aplicacao roda em mais de uma JVM, ai sim pode ser que vale a pena manter essa separação, mas isso PODE ser teria que avaliar caso a caso.

No banco? :stuck_out_tongue:

]['s

Desculpa, acho que não fui claro. Vou melhorar a pergunta: Onde seria correto colocar os inserts, updates, deletes ? Neste caso(persistência) você utilizaria uma classe separada?

Valeu…

Ah sim… mais uma coisa. Vocês podem me indicar livros que vocês já leram sobre o assunto…

Obrigado.

[quote=maazevedo][quote=David]
E qual o problema com a persistência? Não vejo nenhuma diferença.
[/quote]

Desculpa, acho que não fui claro. Vou melhorar a pergunta: Onde seria correto colocar os inserts, updates, deletes ? Neste caso(persistência) você utilizaria uma classe separada?

Valeu…

[/quote]

No DAO normalmente.

]['s