O uso do VCL para a Web (Intraweb) como um truque para adicionar interface da Web a um aplicativo Legacy Non Tiered (2 camadas) Delphi Win32 faz sentido?

Question

Minha equipe está mantendo um enorme aplicativo Delphi Winphi Server Win32. É um aplicativo cliente/servidor (cliente grosso) que usa componentes Devart (SDAC) para se conectar ao SQL Server.

A lógica de negócios é frequentemente "presa" nos manipuladores de eventos do componente, de qualquer maneira, com algum grau de refatoração, é possível mover a lógica de negócios em unidades comuns (grande parte deste trabalho já foi feita durante a refatoração ... Mantendo aplicativos legados de alguém alguém Else escreveu é muito frustrante, mas esse é um trabalho muito comum).

Agora, há a solicitação de uma interface da Web, tenho várias opções, é claro, nesta pergunta que quero focar na opção VCL para a Web (intraweb).

A idéia é usar o código comum (os mesmos arquivos PAS) para o aplicativo cliente/servidor e para o aplicativo da Web. Ouvi falar de muitas pessoas que transferiram aplicativos legados de Delphi para Intraweb, mas aqui estou tentando manter o cliente grosso também.

A idéia é usar o código comum, pode ser com algumas diretivas do compilador para escrever código específico:

{$IFDEF CLIENTSERVER}
  {here goes the thick client specific code}
{$ELSE}
  {here goes the Intraweb specific code}
{$ENDIF}

Outro problema é o "Plano de Migração", digamos que eu tenho 300 recursos e, no primeiro lançamento, terei apenas 50 deles disponíveis no aplicativo da Web. Como acompanhar isso? Eu estava pensando em (AB) usando interfaces Delphi para lidar com isso. Por exemplo, para a autenticação do usuário, eu poderia mover todo o código relacionado em um procedimento e declarar uma interface como:

type
  IUserAuthentication= interface['{0D57624C-CDDE-458B-A36C-436AE465B477}']
    procedure UserAuthentication;
  end;

Dessa forma, ao implementar a interface iUserauthentication em ambos os aplicativos (cliente grosso e intraweb), sei que esse recurso foi "portado" para a Web. De qualquer forma, não sei se essa abordagem faz sentido. Fiz um protótipo para simular todo o processo. Funciona para um aplicativo "Hello World", mas me pergunto se faz sentido em uma grande aplicação ou essa ideia de interface é apenas contraproducente e pode sair pela culatra.

Minha pergunta é: essa abordagem faz sentido? (A ideia da interface é apenas uma ideia extra, não é tão importante quanto a parte comum do código descrita acima) é uma opção viável?

Entendo que depende muito do tipo de aplicativo, de qualquer maneira, para ser genérico, o meu está no domínio CRM/contabilidade, e o número de usuários simultâneos em uma única instalação é normalmente menor que 20 com picos de 50.

Comentário extra (atualização): faço essa pergunta porque, como não tenho um aplicativo N-Tier, vejo o Intraweb como a opção exclusiva de ter um aplicativo da Web com código comum com o cliente grosso. Desenvolver serviços Web do código Delphi não faz sentido no meu caso específico; portanto, a alternativa que tenho é escrever a interface da web usando asp.net (duplicando a lógica de negócios), mas neste caso não posso aproveitar o código comum em um jeito fácil. Sim, eu poderia usar DLLs, talvez, mas meu código não é adequado para isso.

Answer 1

A coisa mais importante que você deve lembrar é a seguinte:

• Seu processo grosso .exe é usado por uma pessoa de cada vez (várias pessoas terão várias instâncias disso .exe).
• Seu processo intraweb .exe será usado por muitas pessoas por vez. Todos eles compartilham a mesma instância do processo.

Isso significa que sua lógica de negócios não deve apenas ser reformada em unidades comuns, as instâncias da lógica de negócios devem ser capazes de residir na memória várias vezes e não interferir.

Isso começa com a lógica de negócios que fala com o banco de dados: você deve ter várias conexões de banco de dados ao mesmo tempo (na prática, um pool de conexões de banco de dados funciona melhor).

Na minha experiência, quando você pode refatorar sua lógica de negócios em datamodules, você tem um bom ponto de partida para suportar um Intraweb e uma versão grossa do seu aplicativo.

Você não deve esquecer a interface do usuário:

• Clientes grossos suportam formas modais e têm uma interface de usuário muito mais rica
• Os navegadores da web suportam apenas diálogos de mensagem (e então: esses são muito limitados), todas bons componentes para intraweb)

Então, para finalizar, você deve lidar com a natureza apátrida do protocolo HTTP. Para superar isso, você precisa de sessões. Intraweb cuidará da maior parte da parte da sessão.
Mas você precisa se fazer perguntas como essas:

• O que deve acontecer se um usuário estiver inativo por xx minutos?
• Quanto estado de sessão posso armazenar na memória? E se não se encaixar?
• O que eu faço com o estado da sessão que não se encaixa na memória?

Isso é apenas um começo, então informe -o quando precisar de mais informações.
Se for muito específico para o seu aplicativo, você sempre poderá entrar em contato comigo diretamente: basta pesquisar no Google.

--Jeroen

Answer 2

Acho que se você mover seu aplicativo para N-Tiers será uma solução melhor, será mais fácil depois que isso seja usado pelos aplicativos de desktop e web.

Você já fez a primeira parte dissociando a lógica de negócios da apresentação, você pode usar RemoBject SDK ou DataSnap que empatou com Delphi.

Depois disso, você terá um aplicativo de desktop em funcionamento e poderá usar o intrawebm asp.net ou o que quer que seja para a Web Part, e dessa maneira você não precisará duplicar a lógica de negócios novamente para a Web Part.

Normalmente, convertendo o aplicativo de desktop para a Web não é fácil, como você pensava, porque eles funcionam em um ambiente diferente e você precisa construir cada um como é a natureza.