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" [...] continue lendo...
