Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo Clube Delphi 61 - Migrando para Delphi for .Net
Artigo da Revista Clube Delphi Edição 61.
Atenção: por essa edição ser muito antiga não há arquivo pdf para download desta revista. os artigos disponíveis somente em doc.
Migrando para Delphi for .NET
Parte II - Aplicações ASP.NET,Windows Forms e .NET no Linux(Mono)
Na primeira parte deste artigo (edição 60) vimos alguns cuidados e aspectos gerenciais relativos à migração de aplicações Win32 para .NET. Neste segundo artigo, discutiremos algumas estratégias de migração, ao passo em que desenvolveremos um exemplo prático abordando um cenário clássico dentro desse
contexto. Ao longo deste artigo também teremos a oportunidade de analisar uma série de tópicos relativos à adequação de código Win32 ao compilador .NET, informações essenciais a qualquer pro- cesso de migração.
Analisando estratégias de migração
Dentre as estratégias de migração, a "horizontal" (discutida na primeira parte do artigo) certamente é a mais densa e que provavelmente envolve mais riscos. Isso se deve ao fato de que nela uma camada da aplicação é inteiramente substituída num só passo. Por outro lado, o deploy (distribuição) da solução é simplificado, não
precisaremos tratar com vários módulos seqüenciais, como pode vira ocorrer numa estratégia "vertical".
A primeira decisão a ser tomada em uma estratégia horizontal é qual camada será migrada. Isso obviamente pressupõe uma aplicação multicamadas (mais adiante veremos um estudo de caso envolvendo uma aplicação cliente/servidor). Vale a pena ressaltar que fatalmente estaremos trabalhando com os recursos
de interoperabilidade do .NET ao passar por uma migração horizontal.
Optando-se por migrar a camada de apresentação, teremos um cenário semelhante ao mostrado na Figura 1. Observe na imagem a representação de alguns RCWs (Runtime Callable Wrapper entidade do .NET responsável por permitir que o código gerenciado faça chamadas a código COM / DCOM.
Figura 1. Migrando a camada de apresentação.
No caso de escolhermos migrar a camada de negócio, teremos um cenário semelhante ao mostrado na Figura 2. Observe que agora.no lugar dos RCWs vistos anteriormente, podemos encontrar algumas representações do CCW (COM Callable Wrapper), entidade do .NET responsável por permitir que código não-gerenciado acesse classes codificadas no .NET.
Muitas vezes a estratégia horizontal será a opção mais adequada para uma Solução principalmente quando tal aplicação apresenta um alto nível de acoplamento.
Normalmente as aplicações bem modeladas, que apresentam um baixíssimo nível de acoplamento, são melhores candidatas a uma migração vertical, possibilitando um processo mais controlado e gradual. Nesse cenário passamos a analisar funcionalidades isoladas a serem migradas, não mais camadas inteiras. Nessa decisão incorre dezenas de aspectos, mas em nível geral, quanto menor o acoplamento entre as classes que implementam determinada funcionalidade, mais fácil será migrá-la verticalmente.
Uma maneira formal e mais precisa para medir o acoplamento de uma funcionalidade e evitar surpresas negativas durante o processo é realizar uma análise do código, normalmente chamada codepath. Em linhas gerais isso é muito simples, basta começar a partir da interface da funcionalidade e ir adentrando o código, a partir de chamadas iniciais, tomando nota de seus relacionamentos e dependências. Isso pode ser feito através de depuração do código.
Na Figura 3 podemos ver uma estrutura semelhante a de uma aplicação que passou por um processo de migração vertical.
Figura 2. Migrando a camanda de negócios
Figura 3. Estratégia de migração vertical
Note que as linhas pontilhadas delimitam uma determinada funcionalidade que foi migrada verticalmente, tanto na camada de apresentação quanto na camada de negócio.
É importante observar que esse modelo pode ser aplicado não apenas para migrar código antigo, mas também para inclusão de novos recursos. Como podemos perceber, a estratégia vertical nos dá muita flexibilidade para conduzir um processo de migração, podendo ele ser levado com mais calma e cautela. Ela permite fazer opções estratégicas entre as funcionalidades de nossos aplicativos,
além de possibilitar uma maior agilidade numa eventual necessidade de adequação pontual exigida por nossos clientes.
Boas práticas e patterns
Bom planejamento e boa codificação nunca fazem mal, é verdade, mas em um grande processo de migração, eles podem ser a linha que separa o sucesso do insucesso. É importante ter em mente e no papel qual o real objetivo e, principalmente escopo, do processo. Diante disso, caberá ao desenvolvimento executar um bom papel.
Nesse ponto, quero inclusive abrir um pequeno parêntese para falar rapidamente sobre design patterns. Esse assunto está em moda atualmente, mas sinto que muita gente o tem empregado de forma inadequada, invertendo a ordem das coisas. Não é interessante fazer uma leitura de alguns padrões e tentar achar algum lugar em sua aplicação para encaixá-los, isso seria uma inversão de valores.
Os patterns amplamente divulgados principalmente os descritos pêlos membros da GoF em sua reverenciada obra, são uma fonte inestimável para estudo e entendimento sobre a boa orientação a objetos. O mais importante é desenvolver um bom entendimento da programação orientada a objetos, o resto será apenas consequência disso. Qualquer pessoa que detenha tal conhecimento e entendimento, programa naturalmente patterns, mesmo sem sequer conhecê-los.
Dentro de um processo de migração, principalmente se há o interesse em investir em retro-compatibilidade com o código Win32, uma de nossas melhores ferramentas é a abstração, aliás, dentro de qualquer aplicativo bem modelado. No meu ponto de vista e por"
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
