4

私のチームは、巨大なクライアントサーバーwin32Delphiアプリケーションを維持しています。これは、DevArt（SDAC）コンポーネントを使用してSQL Serverに接続するクライアント/サーバーアプリケーション（シッククライアント）です。

ビジネスロジックは、コンポーネントのイベントハンドラーに「トラップ」されることがよくありますが、いずれにせよ、ある程度のリファクタリングを使用すると、ビジネスロジックを共通のユニットに移動できます（この作業の大部分は、リファクタリング中にすでに実行されています...レガシーアプリケーションを誰かに保守する他の人が書いたのは非常にイライラしますが、これは非常に一般的な仕事です）。

Webインターフェイスの要求があります。もちろん、いくつかのオプションがあります。この質問では、Web（イントラWeb）オプションのVCLに焦点を当てたいと思います。

アイデアは、クライアント/サーバーアプリケーションとWebアプリケーションの両方に共通のコード（同じpasファイル）を使用することです。レガシーアプリをデルファイからイントラネットに移行した多くの人の話を聞きましたが、ここではシッククライアントも維持しようとしています。

アイデアは、一般的なコードを使用することです。特定のコードを記述するために、いくつかのコンパイラ指令を使用する場合があります。

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

次に、もう1つの問題は「移行計画」です。たとえば、300の機能があり、最初のリリースでは、Webアプリケーションで使用できるのはそのうちの50だけだとします。それを追跡する方法は？私はこれを処理するためにDelphiインターフェースを（ab）使用することを考えていました。たとえば、ユーザー認証の場合、プロシージャ内のすべての関連コードを移動して、次のようなインターフェイスを宣言できます。

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

このようにして、両方のアプリケーション（シッククライアントとイントラウェブ）にIUserAuthenticationインターフェイスを実装すると、その機能がWebに「移植」されたことがわかります。とにかく、このアプローチが理にかなっているかどうかはわかりません。プロセス全体をシミュレートするためのプロトタイプを作成しました。これは「Helloworld」アプリケーションで機能しますが、大規模なアプリケーションで意味があるのか​​、それともこのインターフェイスのアイデアは逆効果であり、裏目に出る可能性があるのでしょうか。

私の質問は、このアプローチは理にかなっていますか？（インターフェイスのアイデアは単なる追加のアイデアであり、上記の一般的なコード部分ほど重要ではありません）それは実行可能なオプションですか？

私はそれが多くの種類のアプリケーションに依存することを理解しています、とにかく一般的に私のものはCRM /アカウンティングドメインにあり、単一のインストールでの同時ユーザーの数は通常20未満で、ピークは50です。

追加コメント（更新）：私はn層アプリケーションを持っていないので、イントラウェブをシッククライアントと共通のコードを持つWebアプリケーションを持つためのユニークなオプションと見なしているので、この質問をします。DelphiコードからWebサービスを開発することは私の特定のケースでは意味がないので、ASP.NET（ビジネスロジックを複製する）を使用してWebインターフェイスを作成することもできますが、この場合、簡単な方法。はい、おそらくdllを使用できますが、私のコードはそれに適していません。

4

2 に答える 2

5

あなたが覚えておかなければならない最も重要なことはこれです：

  • シッククライアントの.EXEプロセスは、一度に1人のユーザーによって使用されます（複数のユーザーがその.EXEの複数のインスタンスを持つことになります）。
  • イントラウェブの.EXEプロセスは、一度に多くの人が使用します。それらはすべて、プロセスの同じインスタンスを共有します。

つまり、ビジネスロジックは、共通のユニットにリファクタリングされるだけでなく、ビジネスロジックのインスタンスは、メモリに複数回常駐でき、干渉しないようにする必要があります。

これは、データベースと通信するビジネスロジックから始まります。同時に複数のデータベース接続を確立できる必要があります（実際には、データベース接続のプールが最適に機能します）。

私の経験では、ビジネスロジックをデータモジュールにリファクタリングできる場合、アプリのイントラネットバージョンとシッククライアントバージョンの両方をサポートするための良い出発点があります。

ユーザーインターフェイスを忘れないでください。

  • シッククライアントはモーダルフォームをサポートし、はるかに豊富なUIを備えています
  • Webブラウザーはメッセージダイアログのみをサポートし（そして、それらは非常に制限されています）、すべての凝ったUIのものは多くの開発時間を要します（たとえば、TMSにはIntraweb用のいくつかの優れたコンポーネントがあります）

次に、それを締めくくるには、HTTPプロトコルのステートレスな性質に対処する必要があります。これを克服するには、セッションが必要です。Intrawebがセッション部分のほとんどを処理します。
ただし、次のような質問をする必要があります。

  • ユーザーがXX分間アイドル状態の場合はどうなりますか？
  • どのくらいのセッション状態をメモリに保存できますか？そしてそれが収まらない場合はどうなりますか？
  • メモリに収まらないセッション状態をどうすればよいですか？

これはほんの始まりに過ぎないので、さらに情報が必要な場合はお知らせください。
それがあなたのアプリに非常に特有であるならば、あなたはいつでも私に直接連絡することができます：ただ私をググってください。

--jeroen

于 2010-05-11T16:21:37.830 に答える
1

アプリケーションをn層に移動すると、より良いソリューションになると思います。その後、デスクトップおよびWebアプリケーションで使用するのが簡単になります。

ビジネスロジックをプレゼンテーションから切り離して最初の部分を作成したので、DelphiにバンドルされているRemObjectSDKまたはDataSnapを使用できます。

その後、デスクトップアプリケーションが機能し、WebパーツにIntrawebm Asp.netなどを使用できるようになります。このようにして、Webパーツのビジネスロジックを再度複製する必要がなくなります。

デスクトップアプリケーションは異なる環境で動作するため、通常、デスクトップアプリケーションをWebに変換するのは簡単ではありません。また、その性質上、それぞれを構築する必要があります。

于 2010-05-11T21:13:26.743 に答える