¿Tiene sentido usar VCL para la web (intraweb) como truco para agregar una interfaz web a una aplicación Delphi win32 heredada sin niveles (2 niveles)?

Question

Mi equipo mantiene una enorme aplicación Client Server win32 Delphi.Es una aplicación cliente/servidor (cliente grueso) que utiliza componentes DevArt (SDAC) para conectarse a SQL Server.

La lógica de negocios a menudo está "atrapada" en los controladores de eventos de Component; de todos modos, con cierto grado de refactorización es factible mover la lógica de negocios en unidades comunes (una gran parte de este trabajo ya se ha realizado durante la refactorización...Mantener aplicaciones heredadas que otra persona escribió es muy frustrante, pero es un trabajo muy común).

Ahora está la solicitud de una interfaz web, tengo varias opciones por supuesto, en esta pregunta quiero centrarme en la opción VCL para la web (intraweb).

La idea es utilizar el código común (los mismos archivos pas) tanto para la aplicación cliente/servidor como para la aplicación web.Escuché de muchas personas que trasladaron aplicaciones heredadas de Delphi a intraweb, pero aquí estoy tratando de mantener también el cliente Thick.

La idea es utilizar código común, puede ser con algunas directivas del compilador para escribir código específico:

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

Luego, otro problema es el "plan de migración", digamos que tengo 300 funciones y en la primera versión solo tendré 50 disponibles en la aplicación web.¿Cómo realizar un seguimiento?Estaba pensando en (ab)usar interfaces Delphi para manejar esto.Por ejemplo, para la autenticación de usuario, podría mover todo el código relacionado en un procedimiento y declarar una interfaz como:

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

De esta manera, cuando implemento la interfaz IUserAuthentication en ambas aplicaciones (Thick Client e Intraweb), sé que esa característica ha sido "portada" a la web.De todos modos, no sé si este enfoque tiene sentido.Hice un prototipo para simular todo el proceso.Funciona para una aplicación de "Hola mundo", pero me pregunto si tiene sentido en una aplicación grande o si esta idea de interfaz solo es contraproducente y puede resultar contraproducente.

Mi pregunta es:¿Tiene sentido este enfoque?(La idea de la interfaz es sólo una idea adicional, no es tan importante como la parte del código común descrita anteriormente) ¿Es una opción viable?

Entiendo que depende mucho del tipo de aplicación; de todos modos, para ser genérico, la mía está en el dominio CRM/Contabilidad, y la cantidad de usuarios simultáneos en una sola instalación suele ser inferior a 20 con picos de 50.

COMENTARIO ADICIONAL (ACTUALIZACIÓN):Hago esta pregunta porque como no tengo una aplicación de n niveles, veo a Intraweb como la opción única para tener una aplicación web que tenga código común con el cliente pesado.Desarrollar servicios web a partir del código Delphi no tiene sentido en mi caso concreto, por lo que la alternativa que tengo es escribir la interfaz web usando ASP.NET (duplicando la lógica de negocio), pero en este caso no puedo aprovechar el código común en un camino fácil.Sí, tal vez podría usar dlls, pero mi código no es adecuado para eso.

Answer 1

Lo más importante que debes recordar es esto:

• El proceso .EXE de su cliente pesado lo utiliza una persona a la vez (varias personas tendrán varias instancias de ese .EXE).
• Su proceso intraweb .EXE será utilizado por muchas personas a la vez.Todos comparten la misma instancia del proceso.

Eso significa que su lógica de negocios no solo debe refactorizarse en unidades comunes, sino que las instancias de la lógica de negocios deben poder residir en la memoria varias veces y no interferir.

Esto comienza con la lógica empresarial que se comunica con la base de datos:debe poder tener múltiples conexiones de bases de datos al mismo tiempo (en la práctica, un conjunto de conexiones de bases de datos funciona mejor).

En mi experiencia, cuando puedes refactorizar tu lógica de negocios en módulos de datos, tienes un buen punto de partida para admitir una versión Intraweb y de cliente pesado de tu aplicación.

No debes olvidar la interfaz de usuario:

• Los clientes pesados ​​admiten formularios modales y tienen una interfaz de usuario mucho más rica
• Los navegadores web sólo admiten cuadros de diálogo de mensajes (y luego:son muy limitados), todas las cosas sofisticadas de la interfaz de usuario cuestan mucho tiempo de desarrollo (aunque, por ejemplo, TMS tiene algunas buenos componentes para Intraweb)

Luego, para colmo, hay que lidiar con la naturaleza sin estado del protocolo HTTP.Para superar esto, necesitas sesiones.Intraweb se encargará de la mayor parte de la sesión.
Pero es necesario hacerse preguntas como estas:

• ¿Qué debería pasar si un usuario está inactivo durante XX minutos?
• ¿Cuánto estado de sesión puedo almacenar en la memoria?¿Y si no encaja?
• ¿Qué hago con el estado de la sesión que no cabe en la memoria?

Esto es solo el comienzo, así que avísenos cuando necesite más información.
Si se vuelve muy específico para tu aplicación, siempre puedes contactarme directamente:solo googleame.

--jeroen

Answer 2

Creo que si mueve su aplicación a n niveles será una mejor solución, después será más fácil de usar para las aplicaciones web y de escritorio.

Ya hiciste la primera parte desacoplando la lógica de negocios de la presentación, puedes usar Objeto Rem SDK o DataSnap incluido con Delphi.

después de eso, tendrá una aplicación de escritorio funcional y podrá usar Intrawebm Asp.net o lo que sea para el elemento web, y de esta manera no tendrá que duplicar la lógica empresarial nuevamente para el elemento web.

Por lo general, convertir una aplicación de escritorio a web no es tan fácil como pensaba, porque funcionan en entornos diferentes y es necesario crear cada una según su naturaleza.