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.

Comments

• Anonymous
  November 06, 2008
  PingBack from http://www.tmao.info/evoluindo-frameworks-domesticos-por-onde-comecar/

• Anonymous
  November 06, 2008
  The comment has been removed

• Anonymous
  November 06, 2008
  Olá Zé Felipe, tudo certo? Obrigado pelos comentários no blog. Concordo com você. É função do arquiteto conhecer diferentes tecnologias, patterns e inspirações que o auxiliem na fase de definição de uma arquitetura. Ainda, é importante acompanhar a evolução do mercado, para que não reinventemos a roda. Antes de construir uma camada de sincronização, vamos avaliar o Sync Framework; para uma camada de cache, acompanhar a evolução do Velocity; para uma camada de persistência, avaliar o Entity Framework também, etc. :) Claro, estou aproveitando o espaço do blog para fornecer o máximo de informações sobre esses recursos da plataforma Microsoft, onde sou arquiteto. Conhecer diferentes abordagens e considerações de arquitetura permite sempre uma maior segurança em nossa caminhada e decisões. Um abraço! Waldemir.

• Anonymous
  November 18, 2008
  Grande Waldemir! excelente artigo! o mais interessante foi seu mapeamento sobre "se você usa X, vá para Y" para tornar o processo de adaptação para a nova realidade de Services (.NET Services, Azure, nuvem, etc).. Gostei muito do destaque dado ao Windows Azure, .NET Services e demais frentes que estão surgindo! Show!!! Abração!

• Anonymous
  November 18, 2008
  Olá Marcondes, tudo certo? Obrigado pelos comentários aqui no blog. Vale notar que cada equipe pode montar sua estratégia de evolução, de acordo com as necessidades da empresa, oportunidades de mercado e limitações de recursos, como orçamento, tempo e pessoas. Esses dias conversei com outra empresa sobre o mesmo assunto e o inventário de aplicações apresentado para a migração chegava aos 2000 sistemas. Será que precisamos mesmos migrar todas as aplicações que estão na plataforma antiga? Precisamos atualizar todos os componentes que estão no WinDNA, COM+ ou em Web Services .asmx? Assim, outro aspecto que vale notar é que o momento da análise para migração também pode ser aproveitado para a consolidação. Dos anos 90 para cá, muita coisa mudou em termos de necessidades da área de negócios. Além da própria consolidação de sistemas, é possível que alguns recursos ou funcionalidades nem sejam mais necessárias, poupando-nos algumas horas de modelagem. Mais um ponto para estudo em nossa jornada rumo à arquitetura Software + Services. Grande Abraço! Waldemir.

• Anonymous
  December 02, 2008
  Olá pessoal, tudo certo? Alguns posts atrás, falamos sobre os desafios para a evolução de soluções baseadas

• Anonymous
  January 30, 2009
  Opnião ! Boa tarde a todos ! O que vcs acham sobre uma camada DTO totalmente baseadas em interfaces ? Exemplo: interface icliente {  string Nome {get;set}; } class cliente:icliente { private string nome; string Nome{ get {  return nome; } set { nome = value; } ... Vi ganhos no ponto de vista por reaproveitar o modelo DTO em projetos antigos por exemplo... Mas estou com alguns problemas para usá-los como data contracts do WCF... Gostaria muito da opnião de todos !

• Anonymous
  February 02, 2009
  Waldemir, sempre diz uma grande verdade "Tudo depende". Minhas preferências tem sido por reaproveitar o que os frameworks de acesso a dados podem providenciar, será que o EF não tem algo para fazer o DTO? O por quê desta preferência? Prefiro focar o meu esforço em definir os partes do meu projeto. E por final, por quantas camadas o dado da sua aplicação navega desde que há entrada do dado na interface gráfica até a sua persistência? O sobre-camadas pode ser tornar um item de atenção quando tivermos que dar manutenção na aplicação, ou documentar os seus níveis. abs.