Evoluindo frameworks domésticos : por onde começar?

Olá pessoal, tudo certo?

Esta semana estive com alguns arquitetos, falando sobre como evoluir os frameworks domésticos que estão em produção nas empresas, mas que ainda utilizam recursos do .NET 2.0 ou algum namespace do .NET 3.0 apenas. Essa discussão é grande e veja que ainda existem empresas usando VB5, VB6, ASP, .NET 1.0, 1.1 ou .NET 2.0 em suas aplicações. Mas vamos focar os frameworks neste post.

Realmente, desde o lançamento do .NET 2.0, tivemos uma série de novos pacotes e namespaces, que ajudam no desenvolvimento de aplicações cada vez mais sofisticadas. Parte dessa evolução foi demandada pelo mercado, como REST e AJAX. Outras, foram evoluções importantes para o modelo de programação na plataforma Microsoft, como o próprio WCF - Windows Communidation Foundation. Vale lembrar também que a própria plataforma amadureceu, diante dos vários cenários presentes no mercado.

Como já vimos em posts passados (esse, por exemplo), existem diversos desafios na construção e manutenção de bibliotecas, blocos de aplicações e frameworks de desenvolvimento, sejam horizontais ou verticais. Um dos grandes desafios é a manutenção de sua atualização diante de novos recursos do mercado, como por exemplo, novos frameworks associados ao .NET na plataforma Microsoft.

Para contextualizar nossa discussão, veja o diagrama abaixo, onde destaco o .NET Framework e sua evolução:

Note que novos recursos foram sendo adicionados na pilha .NET ao longo de suas versões. Ainda, alguns novos pacotes estão faltando no desenho acima, como o SYNC Framework, o Velocity, o Geneva Framework, etc. Para todas as versões acima, estamos trabalhando sobre a mesma CLR - Common Language Runtime, o que significa que não existe quebra de compatibilidade para uma aplicação durante sua evolução de upgrade. O próprio Visual Studio 2008 já compila para .NET 2.0, 3.0 e 3.5 como framework alvo.

Semana passada vimos uma nova enxurrada de frameworks, pacotes de desenvolvimento e serviços que estarão disponíveis em breve para nossas aplicações. Poderemos integrar o ambiente cliente, o ambiente enterprise e o ambiente na nuvem, utilizando recursos distintos e complementares, compondo soluções de acordo com nossas necessidades. Só para para lembrar, veja o que está chegando com a plataforma de serviços Azure... :)

Bastante coisa, não é mesmo? Mas voltemos para nossa pergunta básica: Como evoluir nosso velho framework de desenvolvimento doméstico de todo dia?

Algumas recomendações que faço nesse momento são:

• Se você ainda trabalha com Web Services na plataforma .NET 2.0 (extensões .asmx), ou ainda possui soluções via .NET Remoting, comece com algumas provas de conceito sobre o WCF - Windows Communication Foundation. Podemos resumir que WCF é hoje a infra-estrutura recomendada para a comunicação entre sistema, processos e aplicações na plataforma Microsoft. Uma evolução natural de seu framework em NET 2.0 para .NET 3.x é substituir .NET Remoting e Web Services por interfaces em WCF. Avalie os bindings diferentes para cada serviço e selecione o que melhor responde às necessidades de seu negócio. Veja as considerações sobre balanceamento de carga com o WCF também. O WCF é parte integrante do .NET desde a versão 3.0 e com certeza é uma primeira abordagem de evolução, pelo ganho de desempenho e modelo de programação unificado que oferece. Não deixe de conferir também, os vários cenários possíveis para serviços com WCF, aqui;

• Se você ainda trabalha com páginas ASP, avalie o ASP.NET com AJAX. Veja alguns exemplos disponíveis no link : https://www.asp.net/community/projects/. Existem boas idéias que podem ser aproveitadas em seus projetos. Ainda, avalie exemplos com AJAX para ganhos de produtividade e performance, otimizando suas requisições junto ao servidor ou mesmo melhorando a usabilidade na navegação do usuário sobre suas páginas. Finalmente, navegar dados via ASP.NET Dynamic Data ou exporta um banco de dados através da interface ADO.NET Data Services, com consultas via REST é uma outra boa recomendação para prova de conceito. Não deixe de testar essas soluções;

• Se você possui um framework que prevê interfaces WinForms com .NET, ou formulários VB6 com Win32, por exemplo, avalie os recursos de usabilidade e navegação obtidos com o WPF - Windows Presentation Foundation. Além de um conjunto muito mais rico de controles gráficos e interação com o usuário, o desenvolvimento sobre WPF permite maior integração entre os times de design e desenvolvimento, devido o uso de documentos em XAML - Extensible Application Markup Language, que permitem a renderização gráfica baseada em parsers, integrados ao .NET Framework, na ferramenta de design ou no próprio Visual Studio;

• Se você ainda utiliza o ADO.NET 2.0 para navegar seus dados e manipular suas estruturas de retorno a partir de consultas ao banco de dados, através de um camada DAL - Data Access Layer - tradicional, avalie consultas utilizando LINQ - Language Integrated Query, do .NET 3.5. Verifique o tipo de legibilidade de código que você pode obter com o LINQ, assim como consultas sobre coleções com o XLINQ sobre XML, ou o uso integrado do ADO.NET Entity Framework (EF) , permitindo a construção de soluções multi-banco. Sua prova de conceito com LINQ e Entity Framework também poderá avaliar performance, tempo de resposta e aderência ao SLA esperado pela aplicação, comparando com uma DAL simples. Vale citar que manutenção e independência de banco de dados são pontos de destaque nessa infra-estrutura LINQ + EF (veja sua necessidade de ORM - Object Relational Mapping e camadas de persistência). LINQ é parte do .NET desde a versão 3.5 e o ADO.NET Entity Framework, desde a versão 3.5 SP1. Veja mais aqui;

• Se você ainda possui regras de negócio no COM+ (1.0 e 1.5) ou algumas regras em Web Services publicados no IIS, avalie a exportação de suas regras como serviços WCF, hosteados no WAS - Windows Process Activation Services. Muita calma nesse momento, devido questões de transação, interoperabilidade com componentes legados, etc. Mas entre os benefícios do host WAS para serviços WCF temos um melhor desempenho para o tratamento de requisições e instâncias, assim como maior flexibilidade na seleção de protocolos de transporte e adoção de um modelo orientado a mensagens, mais flexível quanto a integração com outras plataformas. Sobre o Windows Server 2008, WAS torna-se é uma recomendação de fato. Veja mais aqui;

Com certeza, esse é um post apenas para dar algumas idéias, iniciar uma discussão. Cada empresa encontrará sua melhor abordagem, de acordo com uma série de fatores próprios, como:

• maturidade do framework em produção na empresa;
• maturidade da equipe de desenvolvimento usuária do framework;
• maturidade da equipe de arquitetura responsável pelo framework;
• existência de templates e bons exemplos de código utilizando o framework;
• maturidade do processo de desenvolvimento de software e existência de disciplinas de ALM - Application Lifecycle Management;
• seleção de arquiteturas de referência e boas práticas de desenvolvimento, que sejam suportadas pelo framework, etc.

O mais importante é definir uma estratégia de evolução, procurando atender as principais necessidades do usuário, seja desempenho, usabilidade, velocidade para adição de novas funcionalidades, riqueza de interface, funcionalidades de integração com a web ou simplesmente, a competição com o mercado.

A discussão é boa! O desafio também é bom!

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

Waldemir.