Frameworks de desenvolvimento e blocos de aplicação

Olá pessoal, tudo certo?

Semana passada estive com alguns times falando sobre frameworks de desenvolvimento. Esse assunto está sempre em alta, principalmente em tempos de crise, quando produtividade, padronização e qualidade de software ganham uma certa importância.

Existem várias questões envolvidas em projetos de frameworks, tanto que já tivemos por aqui um post sobre esses desafios, confira!

Uma pergunta que surgiu durante a discussão foi sobre a diferença entre blocos de aplicações e frameworks de desenvolvimento. Pergunta interessante, respondi da seguinte maneira…

Podemos definir blocos de aplicações como peças de código que são comuns em diversos projetos de software. Exemplos de blocos são componentes de cache, logging, validação, monitoração, etc. Uma empresa que coleciona blocos de aplicações pode reaproveitá-los durante o desenvolvimento de diversos sistemas. Ao longo do tempo, para um mesmo domínio de aplicação teremos diversas aplicações utilizando os mesmos blocos construtivos, conforme a necessidade. Ganha-se com o reuso e com a previsibilidade de comportamento desses componentes, que amadurecem ao longo do tempo, com as constantes intervenções e depurações. Veja a figura abaixo que ilustra esse cenário:

Já um framework de desenvolvimento envolve uma solução inicial dentro de um domínio de solução ou problema. Essa solução inicial envolve certos blocos construtivos que ajudam na solução, como componentes de acesso a dados, configuração, logging, monitoração, etc. muitas vezes os mesmos componentes que antes funcionavam apenas como blocos de aplicação. O ponto chave desse cenário é a coordenação dos vários elementos dentro do mesmo domínio, fornecendo um ambiente para a construção de nossas aplicações. O framework oferece assim uma solução inicial para novas aplicações. Assim, ilustro um framework de desenvolvimento através da figura abaixo, onde cada aplicação é imersa dentro do ambiente fornecido pelo framework, veja:

O que vocês acham? Compraram as definições acima?

Seja para a adoção de blocos de aplicação ou para a construção de frameworks de desenvolvimento, continuo sugerindo a Enterprise Library 4.1 como um bom começo. Ela oferece bons exemplos e alguns cenários de forma antecipada, economizando muita codificação durante nossos projetos.

Para pensar: atualmente, estamos com o .NET 3.5 SP1 e em breve o .NET 4.0 será lançado. Novos frameworks e templates têm sido anunciados como Velocity, .NET RIA Services, Sync Framework, Live Framework, entre outros. Esse processo é contínuo e com certeza, novos protocolos e modelos de programação devem surgir ao longo dos anos. Oslo também desponta no horizonte próximo. Por isso, ao projetar seu framework de desenvolvimento, pense sempre em MUDANÇA, e até espere por ela!!! Isso fará seu projeto mais flexível, suportando adaptações futuras, versionamento de interfaces, configuração dinâmica e composição de funcionalidades.

Se o ritmo continuar o mesmo, 2009 (.NET 4.0), 2010 (.NET 5.0), 2011 (.NET 6.0), 2012 (.NET 7.0), 2013… brincadeirinha, mas você já entendeu, certo?

Como já disse Heráclito de Éfeso, 500 a.C. “Panta rhei”, isto é, “Tudo flui”, “Tudo é movimento”, “Tudo muda” !!! :)

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments

• Anonymous
  July 16, 2009
  Olá Waldermir, Concordo com suas definições, acredito também que a partir da customização e agragação de novas funcionalidades em blocos de aplicações teremos um framework de desenvolvimento. []'s Fernando Pereira

• Anonymous
  July 16, 2009
  Olá Fernando, Sem dúvida, dependendo de como você define cada conceito, essa evolução de blocos de aplicação para frameworks existe sim. Em ambos os casos, produtividade, maturidade do código usado, reuso e previsibilidade de comportamento são alvos comuns. []s Waldemir.

• Anonymous
  September 04, 2009
  Bela análise. As duas são boas soluções, basta saber sua necessidade. Eu vejo um framework para algo mais para fábrica de soft. ex.: 20 sistemas pra 20 empresas diferentes, mas são praticamente igual: Mesma interface, mesmo comportamento, um novo programador sai de um projeto e cai em outro e a curva de aprendizado é mto baixa. Tb acredito q a evolução natural dos application block é virar um framework. A grande responsabilidade pra mim é a interoperabilidade. Com os application block, um não afeta o outro (acredito eu). Já num framework, vc tem q saber q um ajuste aqui, pode mudar mta coisa em mtos lugares.

• Anonymous
  September 06, 2009
  Olá Rodolfo, É isso ai, concordo com vc. O cuidado com a interoperabilidade é importante. Ao mesmo tempo, a curva de aprendizagem de um novo desenvolvedor deve ser menor, com um framework bem definido. []s Waldemir.