Alguem usa MVC e JSF de verdade?

Assuntos Gerais
#1

Eu tenho lido um bocado para tentar me convencer que desenvolver com MVC, IOC, JSF faz as aplicações melhores e mais robustas. Neste momento estou lendo “Core JavaServer Faces Fundamento” - Geary & Horstmann.

O problema é que eu não consigo ver isto. Eu apenas vejo estas ferramentas como consumidoras de tempo de desenvolvimento. Não consigo ver em que todos estes desacoplamentos melhoram o tempo de desenvolvimento.

Todos os exemplos que vejo nunca passam de telas bobinhas com poucos campos e poucas ações.

Quando eu penso em desenvolver uma página várias informações de um contas a pagar por exemplo com vários campos e niveis de aninhamento e totalizadores. Por exemplo o resumo de um fornecedor, precisa aparecer os dados básicos do fornecedor, os diversos endereços e telefones dele, os títulos que temos a pagar, as parcelas destes titulos se for o caso, os pagamentos efetuados e as parcelas quitadas, vencidas e a vencer.

Aí me pego a pensar em um managed bean gigante com diversos arrays tais como endereços, telefones e titulos, além do nome, CPF, etc
Os títulos seriam consituidos por arrays outros beans como parcelas e pagamentos. Isto não é muito trabalhoso? E a manutenção ao criar novos campos na tela?
Não seria mais simples um JSP lendo o banco de dados e exibindo as informações como fariamos em PHP ou ASP?

Gostaria de ouvir os colegas com mais experiência no assunto.

#2

Colega, quando li tal livro também me deparei com esta preocupação. Afinal, o livro mostra exemplos pequenos, básicos e muitas vezes no estilo documentação mesmo: faça isso aqui com esse componente. Foi ai que procurando um livro no estilo “Como fazer um aplicativo completo com JSF” que achei o do Edson Gonçalves:

http://www.submarino.com.br/produto/1/21390666/dominando+java+server+faces+e+facelets:+utilizando+spring+2.5,+…

O livro não é básico, então é bom ter as noções do Core JSF. Mas pra quem quer ter uma idéia de como fazer um aplicativo completo, é o ideal.

PS: Conheça JPA para não boiar. O Spring é para injeção de dependências e isso é fácil, então você não sofre no livro.

O Projeto em ação na parte aberta, tem tb no livro o admin dele:
http://www.edsongoncalves.com.br/ProjEcommerce/

Bons estudos ai!

#3

De fato, existem telas com vários componentes, e pode até se pensar se isso é ou não é causado por falta de design. Mas enfim…

A complexidade dos vários campos se resolve com uma boa abstração de classes e objetos que reflitam o domínio de problema. E isso é algo que está fora do escopo do MVC (que lida apenas com a representação visual de um domínio, seja ele qual for). Arrays é uma péssima abstração, principalmente numa linguagem como Java.

De qualquer maneira, eu uso MVC de verdade, e costumava usar JSF no passado. Acredito que o que te faz achar o "JSP lendo do banco " tão sedutor seja a falta de vivência na área, e ao fato de raramente ter trabalhado com manutenção de sistemas. Com o tempo, você vai ver que design simples demais é uma má idéia.

#4

Cara… pra trabalhar com meus PFs (os “SISTEMINHAS” da vida), sempre usarei PHP, tenho uma porrada de coisa já pronta, bastando alterar algo aqui e alí, assim como o Layout…

Para projetos Corporativos, onde segurança e escalabilidade são fatores preponderantes, não posso me dar ao luxo de trabalhar sem um padrão, fazendo com que um JSP chame diretamente um método e etc… etc…

Começo logo a imaginar, juntamente com minha euipe, quando estivermos dando manutenção no System, e acredite, haverão muitas manutenções, afinal, não é o “SISTEMINHA” da padaria… Chega dá até arrepio de imaginar tudo preso nas páginas JSP…

Você deve observar bem o escopo do seu projeto. De repente não é viável mesmo usar certas tecnologias, mas e quanto ao MVC, lhe recomendo… se não um MVC, mas adote um padrão… Mesmo em PHP eu uso padrão, é independente de linguagem e lhe ajuda pra KCTi…

Falows :wink:

#5

Trabalho com um sistema realmente grande, porém escrito em ASP. Temos os nossos padrões de programação claros e definidos.

Temos classes de negócios, layers de acesso a banco de dados e tudo o mais. Não temos MVC.

Poucas de nossas páginas web são complexas a ponto de causar preocupações de manutenção. Tenho até uma página que lembraria o pattern managed beans do JSF.

Meus usuários quando olham a página de clientes querem ter uma visão geral do fornecedor, ou seja, compras, titulos, parcelas, pagamentos, ultimos contatos realizados, etc.

Pelo JSF, poucas opções restam se não carregar um bean extremamente complexo com arrays ou listas e fazer o vinculo deste bean com os componentes da página.

Não seria melhor usar o JSP para acessar classes HELPERS que retornam as informações como POJOs? Não é mais rápido produzir assim? Não é mais fácil treinar programadores para trabalhar deste jeito?

Ao contrario do que disse o Leonardo, o MVC obriga certas abstrações como os ActionForms do Struts.

Então, eu queria entender o processo real de trabalho de quem utiliza o pattern MVC com ou sem JSF.

Talvez o livro do Edson Gonçalves me de a luz que estou procurando.

#6

[quote=vgnogueira]Trabalho com um sistema realmente grande, porém escrito em ASP. Temos os nossos padrões de programação claros e definidos.

Temos classes de negócios, layers de acesso a banco de dados e tudo o mais. Não temos MVC.

Poucas de nossas páginas web são complexas a ponto de causar preocupações de manutenção. Tenho até uma página que lembraria o pattern managed beans do JSF.[/quote]

Ter camadas ajuda a reduzir dependências, mas não tem nada a ver com MVC. Talvez não tenha problema de manutenção porque o problema seja simples demais, mas a sua abordagem é inadequado quando a complexidade aumenta.

[quote=vgnogueira]Meus usuários quando olham a página de clientes querem ter uma visão geral do fornecedor, ou seja, compras, titulos, parcelas, pagamentos, ultimos contatos realizados, etc.

Pelo JSF, poucas opções restam se não carregar um bean extremamente complexo com arrays ou listas e fazer o vinculo deste bean com os componentes da página.[/quote]

Os javeiros mais antigos teimam em criar Beans anêmicos que não tem relação entre si, mas é uma péssima idéia porque não retrata bem as dependências inerentes desses objetos no mundo real. É legal um “Bean” ter lista de outros beans, ter métodos além de getters e setters, ter variáveis private realmente encapsuladas. Isso se chama dominío rico. E ainda bem que o JSF incentiva esse modelo.

Essas classes Helpers, eu chamo de Services, e é invocado a partir do Controller da apresentação. E eu ainda prefiro ter o Controller na frente.

É questionável qual abordagem é mais rápida. Eu, como sei bem o MVC, uso-o sem pensar duas vezes, e é bastante rápido para mim.

E não concordo em ensinar jovens programadores a fazer as coisas de maneira fácil e rápida. Nossos futuros programadores precisariam de uma noção formal de design e organização, algo que, infelizmente, nossa porca educação não oferece.

O ActionForm é só do Struts, um framework que não conheço. De qualquer maneira, nós somos “obrigados” a usar um Controller ou um ManagedBean, e não vejo nada de errado nisso. É até melhor assim, porque eu tiro a complexidade que estaria na página e ponho nesse objeto.

#7