Como Sair do Delphi para o .NET - Parte 1

O ano era 2011. Eu já desenvolvia em várias coisas na época, mas Delphi era o que pagava as contas. Tinha um emprego numa empresa curitibana bem tradicional. CLT, cobrança de horários, aumentos até que legais, até que, um belo dia, um aumento me foi recusado e, para justificar a negativa, algumas pessoas resolveram fazer uma retrospectiva de todas as minhas falhas na empresa desde meus tempos como estagiário até então, já um Analista de Sistemas Pleno, ainda que com muita experiência e vários e vários sistemas refatorados até aquele ponto. Senti que já havia passado da hora de mudar. Se eu era lembrado pelas minhas falhas, e não pelos meus acertos, era sinal de que era uma ótima hora para procurar novos ares.

Mas, em Delphi? A Borland já não existia mais. Agora era Embarcadero. O Delphi virou RAD Studio. Anders Hejlsberg já era empregado da Microsoft desde 1996 e desenvolvia o C# com sua equipe há 11 anos. Eu tinha uma experiência com Java, mas começava a achar o Java bem ruim por uma série de motivos (e, de fato, a coisa só piorou até o Java 8, que é melhorzinho, mas os grandes problemas continuam). Eu precisava aprender uma nova linguagem de mercado. A empresa já mexia com C# e o .NET era badalado por lá (as equipes que mexiam com .NET na época eram mais valorizadas que as equipes que mantinham sistemas em Delphi) e tive um curso ministrado pela empresa de C# em 2009, mas nunca me colocaram num projeto comercial. O que fiz?

Bom, eu não lembro exatamente o dia, mas era final de maio de 2011. Fui para casa e inventei um sistema na minha cabeça para desenvolver. A ideia era estudar um pouco por dia até ter condições de fazer um sistema inteiro apenas usando C# e .NET. Minha escolha foi aprender o ASP.NET MVC (na época, o 3) usando os conhecimentos que adquiri estudando Ruby on Rails por hobby em 2009 e 2010. Eu sabia que o Visual Studio 2010 tinha uma versão gratuita, então comecei por ela. Foram 3 meses estudando e um longo caminho das pedras.

Ano passado, um aluno me procurou para fazer o curso, vindo do Delphi. O objetivo era essa renovação. Feito o curso, ele me sugeriu: "Por que não escrever um artigo (ainda que tardio) sobre como sair do Delphi e ir para o .NET?".

Bom, aqui está ele. Vou dividir em partes para maturá-lo aos poucos.

Historinha

O Delphi ganhou força numa época em que a Internet em si não tinha tanta força como hoje. Lembro que a Internet começou a ganhar enorme relevância a partir dos anos 2000, mas até 1999 sistemas web não eram sequer considerados seguros.

É importante dizer que o Delphi era imensamente dependente de tecnologia. Mesmo o Kylix, irmão do Delphi para Linux, era uma implementação do Delphi que rodava em cima de Wine e tinha um compilador Pascal nativo, mas sempre foi muito lento e nunca vingou realmente.

O Delphi sempre teve sua grande força nos componentes visuais e na sua ligação com fontes de dados, o que permitia a confecção de sistemas para Windows muito rapidamente. O Delphi teve muita força até 2000 porque o produto similar da Microsoft, o Microsoft Visual Basic (por sinal, a IDE e linguagem em que aprendi a programar, em 1998) tinha uma linguagem infernalmente ruim de usar à medida que o sistema escrito nela se tornava mais complexo. Já o Delphi, uma clássica linguagem acadêmica, ganhou suporte a orientação a objetos e era capaz de compilar código nativo (esta variação foi batizada com o nome de Object Pascal). Mais organizada e eficiente, teve grande adesão do mercado até 1999. Poderia ter continuado se tivesse sido portada para a Web, o que não aconteceu. Não por iniciativa da Borland, pelo menos. A Embarcadero, por sua vez, ao invés de massificar o produto, o fez mais fechado. Iniciativas livres que surgiram para organizar o Pascal para servir ao desenvolvimento de sistemas Web ficaram pelo caminho.

Com isso, os desenvolvedores Delphi tinham dois caminhos: mudar de linguagem, o que pode ser doloroso para quem já tem uma carreira consolidada (meu caso) ou permanecer trabalhando com Delphi e mantendo sistemas legados.

Como não sair do Delphi

É bom começar o artigo falando sobre como as pessoas evitam de sair do Delphi a todo custo e as implicações que isso pode trazer.

Uma delas é continuar com a Embarcadero, mas não sei até que ponto isso vale a pena. A licença mais básica custa 1400 dólares, e a mais completa 4700. Considerando a enorme quantidade de opções gratuitas, em linguagens com grandes comunidades como C#, Java, Python, Ruby, Scala, Clojure, Golang, etc., e com IDEs e recursos de produtividade que é apenas questão de baixar e instalar, fica muito complicado obter a adesão de novos programadores esponteamente, ao custo de milhares de dólares (os upgrades também são pagos).

A outra é partir para soluções similares. Se a ideia é manter um produto ainda em Desktop, partir para algo livre pode ser uma boa ideia, como a IDE Lazarus. É terrivelmente parecida com o Delphi, o compilador é o Free Pascal e é extensivamente documentada. O único problema, a meu ver, é se sua solução usa plugins de terceiros. O suporte a eles no Lazarus não é muito bom.

Há também aqueles que têm ideias "mais criativas", como comprar uma ferramenta que "converta" uma aplicação Delphi Desktop em uma aplicação Web. O exemplo mais emblemático é o plugin Intraweb, da Atozed Software que é uma aberração: desenvolve-se o projeto no Delphi e o deploy converte a aplicação Delphi em algo Web. O resultado é péssimo. O motor é um interpretador Pascal que funciona em 32 bits, ou seja, indexa apenas 4 gigas de memória. Na aplicação que vi funcionar com isso, o servidor precisava ser reiniciado de tempos em tempos porque a aplicação morria. Uma outra solução adotada pela empresa era a de manter várias máquinas aceitando requisições. Quando uma delas morria, ela era reiniciada e outra subia no seu lugar. Aí era simples: era só limpar o histórico de cookies do navegador que todos os problemas sumiam! Super joia, não?

Também achei.

Coisa linda!

O Paradigma

A questão que deixa o desenvolvedor Delphi mais desconfortável é, com certeza, o paradigma. Isto porque o desenvolvedor tem uma série de hábitos e preocupações alimentadas por anos e anos. Até usar componentes bacanas ajuda, mas bons sistemas em Delphi envolvem conhecer detalhes intrincados de telas, bibliotecas, aspectos de compilação, de código, e assim por diante.

O CRUD aqui é o exemplo tarimbado de onde começa a quebra de paradigma: a clássica tela com um componente de navegação no topo, uma grade (grid) ocupando 90% da área da tela e os componentes de banco de dados, que não são poucos, a saber:

  • Um componente que representa a tecnologia da conexão;
  • Um componente que representa ou uma tabela, ou uma sentença SQL a ser executada para trazer uma projeção do banco de dados relacional. Por projeção quero dizer aqui uma tabela, uma view ou uma função;
  • Um componente que faz a transmissão da massa de dados entre um componente tecnológico e um componente agnóstico, chamado de TDataSetProvider;
  • Um componente que abriga a massa de dados dentro da aplicação, chamado de TClientDataSet, que por sua vez herda boa parte de sua implementação de um componente mais simples (TDataSet);
  • Um componente que liga o componente da massa de dados com componentes visuais, chamado de TDataSource;

E assim, finalmente podemos ligar nossos componentes de dados (na época, chamavam os componentes de data aware, que é a mesma coisa que frameworks como Angular e Aurelia fazem) ao TDataSource. Toda alteração feita em dados será marcada para atualização. Toda nova informação será inserida. Toda informação marcada para exclusão será excluída.

Essa facilidade mágica fez a Microsoft tentar o padrão Web Forms no ASP.NET como o padrão dominante por bastante tempo, o que teve um sucesso moderado e ainda tem uso em muitos sistemas pelo mundo até hoje. Aqui é possível notar a influência do Delphi: os componentes que temos no Web Forms são:

Apenas por analogia podemos ver que não há tanta diferença entre Delphi e .NET. Aqui desenhei o caminho que muitos desenvolvedores tomaram a partir do ano 2000 para a mudança de paradigma. No mais, o que fez a equipe da Microsoft, na época, para completar a conversão?

Resposta: manteve as coisas semelhantes. Ao desenvolver em ASP.NET Web Forms, cada página ASPX possui duas partes: um fonte chamado de .aspx.designer (no lugar do DFM) e outro chamado aspx.cs (no lugar do PAS). Assim, temos um fonte para enunciar o comportamento visual e outro para enunciar os eventos que ocorrem nesta parte de comportamento visual. Alguns outros cuidados foram tomados para manter as coisas parecidas, como a preservação de estados. No próximo texto, vou explicar por que isso virou um problema mais adiante.

Assim sendo, uma grande massa de desenvolvedores passou do Delphi para o Windows Forms, ou ainda para o ASP.NET Web Forms sem muita fricção. Esse passo foi importantíssimo para a consolidação da Web como paradigma de desenvolvimento em ambientes comerciais, acostumados com componentes de dados, estados e formulários.

Só que a Web não é um conjunto de telas do Delphi. A equipe sabia disso, mas procurou emular o ambiente o melhor possível, acredito que para estimular os desenvolvedores que aderiram a abrir a mente conforme os problemas surgissem.

No próximo texto, vamos 9 anos adiante. Os anos 2000 renderam muitos assuntos, sistemas e problemas novos para toda a comunidade ASP.NET.