En utilisant VCL pour le Web (intraweb) comme une astuce pour ajouter une interface Web pour un héritage non-niveaux (2 niveaux) Delphi application win32 est logique?

Question

Mon équipe maintient un énorme serveur client win32 application Delphi. Il est une application client / serveur (client épais) qui utilise des composants DevArt (SDAC) pour se connecter à SQL Server.

La logique métier est souvent « piégé » dans les gestionnaires d'événements de composants, de toute façon avec un certain degré de refactoring il est faisable de déplacer la logique métier dans des unités communes (une grande partie de ce travail a déjà été fait au cours de la refactorisation ... maintaing applications héritées quelqu'un d'autre a écrit est très frustrant, mais cela est un travail très fréquent).

Maintenant, il y a la demande d'une interface Web, j'ai plusieurs options bien sûr, dans cette question, je veux me concentrer sur l'option VCL pour le Web (IntraWeb).

L'idée est d'utiliser le code commun (les mêmes fichiers PAs) tant pour l'application client / serveur et l'application Web. J'ai entendu de nombreuses personnes qui se sont déplacées des applications héritées de delphi à intraweb, mais là, je suis en train de garder aussi le client lourd.

L'idée est d'utiliser le code commun, peut-être avec quelques directives du compilateur pour écrire du code spécifique:

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

Alors un autre problème est le « plan de migration », disons que je 300 caractéristiques et la première version, je n'aurai 50 d'entre eux disponibles dans l'application Web. Comment garder une trace de celui-ci? Je pensais à (ab) en utilisant des interfaces Delphi pour gérer cela. Par exemple, pour l'authentification de l'utilisateur que je pouvais déplacer tout le code dans une procédure connexe et déclarer une interface comme:

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

De cette façon que j'implémentent l'interface IUserAuthentication dans les deux applications (client lourd et Intraweb) Je sais que cette fonction a été « porté » sur le Web. Quoi qu'il en soit, je ne sais pas si cette approche est logique. J'ai fait un prototype pour simuler le processus. Il travaille pour un « Bonjour tout le monde » application, mais je me demande s'il est logique sur une grande application ou cette idée d'interface est seulement contre-productif et peut se retourner contre.

Ma question est: cette approche se sens? (L'idée d'interface est juste une idée supplémentaire, il est aussi important que la partie de code commun décrit ci-dessus) est-il une option viable?

Je comprends cela dépend beaucoup du type d'application, de toute façon d'être générique mon seul est dans le domaine CRM / comptable, et le nombre d'utilisateurs simultanés sur une seule installation est généralement inférieure à 20 avec des pics de 50

COMMENTAIRE EXTRA (MISE À JOUR): Je pose cette question parce que je n'ai pas une application n-tier, je vois Intraweb comme option unique pour avoir une application web qui a un code commun avec le client épais. Le développement webservices à partir du code Delphi n'a pas de sens dans mon cas spécifique, donc l'alternative que j'ai est d'écrire l'interface Web en utilisant ASP.NET (dupliquer la logique métier), mais dans ce cas je ne peux pas tirer parti du code commun dans un moyen facile. Oui, je pourrais peut-être utiliser les DLLs, mais mon code n'est pas approprié pour cela.

Answer 1

La chose la plus importante que vous devez retenir est la suivante:

• Votre épais processus .EXE client est utilisé par une seule personne à la fois (plusieurs personnes auront plusieurs instances de cette .EXE).
• Votre intraweb processus .EXE sera utilisé par de nombreuses personnes à la fois. Ils partagent tous la même instance du processus.

Cela signifie que votre logique métier ne doit pas seulement être refactorisé à en unités communes, les instances de la logique métier doivent pouvoir résider en mémoire plusieurs fois, et ne pas interférer.

Cela commence par la logique métier qui parle à la base de données: vous devez être en mesure d'avoir des connexions de bases de données multiples en même temps (en pratique un pool de connexions de base de données qui fonctionnent le mieux)

.

Dans mon expérience, quand vous pouvez factoriser votre logique métier dans DataModules, vous avez un bon point de départ pour soutenir à la fois une Intraweb et une version client épaisse de votre application.

Vous ne devriez pas oublier l'interface utilisateur:

• clients épais soutenir les formes modales et une interface utilisateur
beaucoup plus riche
• Les navigateurs Web prennent en charge que les boîtes de dialogue de message (et puis: ceux-ci sont très limités), tous les trucs de l'interface utilisateur de fantaisie coûte beaucoup de temps de développement (bien que, par exemple, TMS a une composants belle Intraweb)

Ensuite, pour couronner le tout, vous devez faire face à la nature sans état du protocole HTTP. Pour remédier à cela, vous avez besoin des sessions. Intraweb prendra soin de la plupart de la partie de session.
Mais vous devez vous poser des questions comme celles-ci:

• ce qui devrait se produire si un utilisateur est inactif pendant XX minutes?
• comment état bien puis-je stocker la session en mémoire? et si elle ne correspond pas?
• qu'est-ce que je fais avec l'état de session qui ne rentre pas dans la mémoire?

Ceci est juste un début, alors laissez utiliser le savoir quand vous avez besoin de plus d'informations.
S'il est très spécifique à votre application, vous pouvez toujours me contacter directement. Google me

- jeroen

Answer 2

Je pense que si vous déplacez votre application n-tiers sera une meilleure solution, il sera plus facile après à utiliser par les applications bureautiques et web.

vous avez déjà fait la première partie en découplant la logique métier de la présentation, vous pouvez utiliser RemObject SDK ou DataSnap que fourni avec Delphi.

après que vous aurez application de bureau de travail, et vous pouvez utiliser Intrawebm Asp.net ou ce que pour une partie Web, et de cette façon vous n'aurez pas à dupliquer à nouveau la logique métier pour la partie Web.

conversion généralement application de bureau à Internet pas facile que vous avez pensé, parce qu'ils travaillent dans un environnement différent, et vous avez besoin de construire chacun comme il est dans la nature.