A primeira rede social sobre arquitetura de software do Brasil

Experiencias com Frameworks Java

Ladies and gentleman,

Acho que não ha melhor lugar pra discutir a respeito da arquitetura das Frameworks e padroes EE Java do que aqui, pelo que vi do pessoal a maioria é Javeiro de guerra.

Bom gostaia saber de cada um sua visão e ou experiencias com as ultimas Frameworks de mercado, como Spring, Seam e o proprio JEE padrão, que são as que vejo que mais bombam por ai.

Desde que surgirao as anotacoes e AOP explodiu, IoC nunca foi tao usado e com tanta facilidade, porem essas facilidades na minha opniao estao chegando em um nivel que esta começando a deixar algumas coisas meio medonhas.

Bom vou colocar minha opniao e o que ja vi de cada um, por favor continuem o topico com a opniao de voces, corrijam minhas opnioes, acrescetem, sei la, acho que é um topico importante, pois querendo ou nao estes caras estao ai e crescendo.

Spring
Acho legal a ideia do Spring ate porque ele chegou antes do Java EE 5 e supriu algumas das necessidades que JEE veio a suprir depois. Gostei por que vi que é algo bem organizado e se consegue controlar melhor a arquitetura e desenho do sistema alem de exigir um ambiente menos complexo.
Agora esse cara da performance ? quando a coisa fica grande(muitos usuarios, muitas transacoes...), como esse cara se comporta ? É escalavel ?

Seam
Gostei da ideia do seam e vejo algo parecido com o que houve com o Spring e Java EE5, pelo que vi o que o Seam se propoe com a JSR299 é algo que esta sendo previsto para o Java EE 6, a RedHat que esta fazendo o Jboss dar lucro agora ta saindo na frente com isso, bom o que vi de Seam ao mesmo tempo que achei legal fiquei meio na duvida quanto ao modelo dele, esse lance dele controlar tudo e bem dizer criar camadas virtuais dos componentes da aplicacao com mapeamentos diretos achei legal e ao mesmo tempo meio medonho, a complexidade de gerenciamento disso e margem de furos ou limitações me assusta. Mas para coisas pequenas talvez nao seja uma má ideia.

Java EE
Bom eu particularmente gosto e vou pro lado dos modelos puritanos onde temos mais controle do que estamos fazendo, apesar de que as vezes isso pode causar um aumento de complexidade para equipes de desenvolvimento e outras coisinhas mais, quem ja trabalhou com J2EE 1.4 sabe disso e o que vejo com o Java EE 5, é que ele supre bem a maioria dos modelos de arquitetura para desenvolvimento corporativo sem a necessidade do uso de Frameworks que as vezes so criam uma maneira diferente de fazer as coisas na minha opniao e nem sempre com tantas vantagens assim.

Bom abri esse topico so pra saber a opniao de voces, big masters da arquitetura utilizando Java e saber se minha visao sobre esse topico esta distorcida e melhorar a mesma com a opniao de voces, ainda dava pra falar muita coisa aqui como diz Carol McDonald's "Tudo vai depender de seus requisitos", do que se precisa fazer e blablabla mais acho que nao preciso entrar nesse merito, quero so saber a opniao e ou experiencia de voces a respeito dessas e outras solucoes prontas de mercado.

Abraço a todos,

---
Sds,
Carlos Lacerda

▶ Responder esta

Respostas a este tópico

Permalink Responder até Adriano Tavares em 10 outubro 2008 at 1:38: Olá Carlos,
legal esse tópico! Realmente essa é uma questão enfrentada pelos desenvolvedores Java pela infinidade de frameworks existentes. Mas não é exclusividade da tecnologia Java não. Os profissionais .NET também tem de fazer escolhas. Existem, não com a mesma diversidade do universo Java, frameworks .NET para AOP, Persistência, etc.

Especificamente sobre "Frameworks J2EE", o Marco Aurélio fez uma apresentação, memorável, para o MgJug em 2004. Nela ele apresenta conceitos e discute sobre escolha e uso de frameworks J2EE para produtividade no contexto daquele momento.; ▶ Responder esta

Permalink Responder até Carlos Lacerda em 10 outubro 2008 at 12:31: Muito bom o PPT Adriano, apesar de ser de 2004 os conceitos nao mudaram, talvez algumas framewoks atuais tenham subido um pouco de nivel, mas só, muito boas as explanações do Corélio.; ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 10 outubro 2008 at 12:52: Carlos, bom?

Vou deixar meus 2'Cents OK. Eu costumo pensar sobre frameworks (tecnolgia em geral) sobre dois grandes prismas:

1) A visão da equipe de desenvolvimento
2) A visão da aplicação a ser construída

Nete caso, ao escolher um conjunto de patterns, frameworks ou COTS que resolvam direta ou indiretamente algum requisito funcional e não funcional do sistema, eu sempre me pergunto: Pra quem o framework está agregando valor? Pra equipe de desenvolvimento ou pra aplicação?

Trabalho com Java desde 2001, e de lá pra cá percebo que grande parte dos desenvolvedores escolhem frameworks pelo quão fácil ele torna as coisas na hora de desenvolver. Isso é ruim. Alguns frameworks como o Spring são simplesmente fantásticos sobre produtividade, mas não resolvem algumas premissas básicas do J2EE como acesso em escala, aspectos trancionais e outros componentes.

Sendo assim, na hora de comparar frameworks, vale mais a pena escolhe-los pelo quanto eles agregam a aplicação. Por exemplo, se hoje não houvesse o EJB 3 e JPA, e tivesse que criar uma aplicação que tivesse altos requisitos de crescimento, baixo acomplamento entre as camadas, que tivesse que suportar vários tipos de clientes, iria pensar primeiro em duas coisas:

1) O modelo Web Centric não se apropria (Ferro pro Spring e JBoss Seam)
2) Preciso de uma estragégia de remoting que vai além de simples RMI e SOAP

Neste caso, eu iria sim usar EJB 2.1 + JMS e MDB's + JCA e JAAS. Todas estas 'stacks' já estão no JEE a anos e nunca me deixaram na mão. Elas são trabalhosas de implementar? São claro, é um fim da picada construir uma aplicação nisso. Mas se ela for bem feita, ela irá comprir meus requisitos não funcionais.

Claro que, em alguns cenários, a produtividade da equipe de desenvolvimento chega a ser um requisito não funcional (Em minha experiência, sempre é) e acredito que seja papel do arquiteto de software ou time de arquitetura, prover este requisito não funcional para a equipe. Mas acho que em qualquer projeto arquitetural, trade-offs serão trabalhados, e se por acaso um dado requisito tiver que ser solucionado com um framework, pattern ou COTS que não agregue produtividade para a equipe, eu iria sacrificar o RNF Produtividade e pró do RNF aderência ao requisito X (Ele poderia ser qualquer um dos requisitos listados na ISO 9126).

Enfim, escolher frameworks não deve levar em consideração quão produtivo ele é. Atualmente todos falam mal de XML por que muitas soluções usam isso abusivamente, mas se o requisito fala sobre 'mudar-sem-recompilar' as lindas anotações vão por água abaixo. Mais ainda, deve-se antes de escolher um framework por suas caracteristicas (AOP, IoC) deve-se entender estas caracateristicas. Que valor o IoC agrega ao projeto? Fraco acomplamento? Os patterns Factory-Method e Abstract-Factory também o fazem. Ai vem a duvida, porque então deveria usar o Spring pra isso? Ah, porque quero fazer mais rápido sem ter que implementar as factories, pois o Spring já faz isso :)

Novamente, o desenvolvedor pensa somente na sua própria produtividade! Quem deve se beneficiar do framework é a aplicação, e não o desenvolvedor!

Abraços,; ▶ Responder esta

Permalink Responder até Carlos Lacerda em 10 outubro 2008 at 14:15: Ricardo,

Você conseguiu dizer exatamente o que penso com relação as frameworks, expressou o que penso como eu nao conseguirira. Muito Obrigado.

Acho que realmente o que se vê em muitos lugares por ai é o uso abusivo de frameworks, muitas vezes desnecessario exatamente por apenas acelar alguns fases no desenvolvimento do software e muitas vezes isso causando problemas implicitos ao uso desses caras dificeis de resolver ate mesmo por falta de conhecimento ou de estudo do mesmo antes de se partir pra pratica.

Trabalho com Java desde de 2003 e tambem nunca precisei de fazer uso extensivo de nenhum Framewok que nao fosse suprido pelas Specs sem grandes dificuldades.

Acho que deve se colocar numa balanca de precisao "Padrao x Frameworks" e a cada dia que passa as Specs estao deixando cada vez mais Frameworks absoletas na minha opniao.

Algo que vejo tambem é que estao surgindo desenvolvedores cada dia mais orientados as Frameworks, nao sei se isso é bom ou ruim.

Valew Ricardo.; ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 10 outubro 2008 at 15:03: Bom demais, Carlos!

Acho a idéia de discutir "Padrões x Frameworks" muito interessante, e acrescento mais: Ela se aplica também ao pessoal de .NET :)

Até quando usar padrões é sadio? O nivel de interoperabilidade com o advento dos padrões realmente existe? Digo, quem hoje conseguiu portar uma aplicação 100% J2EE de um ApplicationServer X para um ApplicationServer Y alterando apenas deployment descriptors? IMHO isto é "Ilusions Mr Anderson, Illusions. Vagaries of Perception!"

Forte abraço!; ▶ Responder esta

Permalink Responder até Marco Mendes em 10 outubro 2008 at 15:19: Acabei revendo a apresentação aqui, Adriano. Obrigado pela lembrança.

A historinha nerd do site da SUN continua atual, mas felizmente a reputação dos EJBs melhorou muito desde 2004. EJBs são realmente persistentes!!!!

Adriano Tavares said:
Olá Carlos,
legal esse tópico! Realmente essa é uma questão enfrentada pelos desenvolvedores Java pela infinidade de frameworks existentes. Mas não é exclusividade da tecnologia Java não. Os profissionais .NET também tem de fazer escolhas. Existem, não com a mesma diversidade do universo Java, frameworks .NET para AOP, Persistência, etc. Especificamente sobre "Frameworks J2EE", o Marco Aurélio fez uma apresentação, memorável, para o MgJug em 2004. Nela ele apresenta conceitos e discute sobre escolha e uso de frameworks J2EE para produtividade no contexto daquele momento.; ▶ Responder esta

Permalink Responder até Alex Reis em 10 outubro 2008 at 17:54: Coincidentemente em uma lista sobre Linux "esbarrei" com uma referência recente sobre este assunto: http://pajeonline.blogspot.com/2008/10/struts-jsf-gwt-qual-o-melhor...; ▶ Responder esta

Permalink Responder até Ricardo Ferreira em 28 outubro 2008 at 14:44: Diego,

É bem verdade que o uso improprio de frameworks num projeto pode levar a isso, mas não concordo plenamente que usar o "artesanal" resolva o problema. Acho que é uma solução um pouco míope. Vou te dar um exemplo até mesmo no âmbito de .NET, pois apesar de ser um cara de Java, já tive a oportunidade (até recente) de trabalhar com coisas de .NET e atuar com uma equipe fera nesta plataforma.

Se você optar por não usar o ASP.NET Ajax por não se sentir confortável em que tipo de estrutura o framework incorpora na solução final, e optar por usar ASP.NET puro, você pode acabar tendo os mesmos problemas com ViewState, HTML entupido de lixo de hidden fields, etc. Isso na verdade está relacionado a conhecer a plataforma por trás dos frameworks.

No caso de Java, isso acontece com certa frequência. Muitos desenvolvedores Java usam frameworks como Spring MVC, Tapestry, Struts, JSF, e não conhecem os arcabouços arquiteturais que estão por trás deles. Já conversei com um desenvolvedor Java que não sabia o que era um Front Controller e muito menos sabia que este componente básico de qualquer framework Web é implementado como um Servlet. Não sei te falar como isso se desenrola no mundo do ASP.NET (não conheço o arcabouço da plataforma) mas acredito que isso possa ser resolvido com um pouco de experiência na plataforma.

No final das contas, isso está mais ligado ao tipo de experiência do desenvolvedor na plataforma. Desenvolvedores mais experientes tendem a conhecer mais sobre como funciona os bastidores de um framework e com isso, eles conhecem que tipo de problemas e efeitos colaterais o mesmo possa gerar.

Uma forma de contornar este problema num projeto, é no inicio do projeto (Na fase de elaboração, por exemplo) preparar um plano de capacitação da equipe nas soluções usadas na arquitetura, bem como elaborar um conjunto de diretrizes arquiteturais que devem ser reforçadas durante a construção do projeto. Isso pode ser facilmente feito usando a grande dica que o Adriano Tavares deu sobre architecture enforcement usando AOP compilado (AOP estático).

Deixar um framework ser usado "de qualquer jeito" num projeto representa falta de atenção com aspectos arquiteturais, algo que é até frequente em algumas empresas e cenários, onde arquitetura de software ainda não é uma realidade, ou é mas não há tempo e orçamento para sustentar tais práticas. Uma pena, mas uma realidade em muitas empresas e pessoas. Mas a solução a este problema é por ai ;); ▶ Responder esta

Permalink Responder até Fabiano G. Souza em 3 dezembro 2008 at 7:29: Um dos piores males que assola o mundo do desenvolvimento, em especial JEE, é a frameworkits aguda! Se escolhe um framework porque é o da moda, é o bacana, é o estiloso, etc. Embora saibamos que uma arquitetura deva ser definida para cada projeto, eu em especial tendo a manter um certo padrão no que se refere ao uso de frameworks pois facilita o treinamento da equipe, padronização das aplicações, escolha das fábricas de software, aprofundamento no conhecimento do framework ao longo do tempo, etc.
O framework seria um dos elementos da arquitetura de referência.
De certo modo existiria, por exemplo, um framework padrão para aplicações web, e a cada projeto avaliamos se esse framework tem um bom casamento com a arquitetura necessária e requisitos não funcionais. Caso o framework seja razoavelmente compátivel, o mantemos.; ▶ Responder esta

Permalink Responder até Braulio Consani Moura em 10 dezembro 2008 at 17:54: Caro Carlos,

Gostaria de aproveitar sua deixa para levantar aqui uma questão relativa a utilização de frameworks da camada web, que, em boa parte estão embutidos nos módulos dos frameworks citados, porém, há diversas soluções integráveis de frameworks deste gênero.

Podemos citar dois grupos de frameworks web que vêm se destacando atualmente: orientados a requisições e os orientados a componentes, se podemos assim dizer (por simplicidade não esmiuçarei os detalhes técnicos das nomenclaturas).

O struts e spring MVC, por exemplo, se encaixam no primeiro grupo, enquanto JSF, typestry, Wicket, se encaixam no segundo grupo. Estou trabalhando num projeto onde o wicket está sendo utilizado e ele tem uma filosofia de programação e arquitetura que se aproximam muito do desenvolvimento desktop com Swing, e, de certa forma, consegue simplificar bem as coisas, causando este lado perigoso de encobrir os fundamentos em prol da produtividade.

Tenho uma impressão sobre a qual gostaria da impressão dos amigos para compartilhar, refutar ou complementar. Me parece que o mercado está tendendo à utilização de frameworks web direcionados a componentes, neste caso, percebo uma baixa adoçao da recente versão 2.0 do Struts por exemplo. Pode ser uma percepção falha, por isso peço a colaboração dos demais colegas.

Abraços
consani; ▶ Responder esta