1

私が書いているASP.NETアプリケーションでは、特定のサーバーへの接続を使用する必要があります（DBのようなものですが...異なる）。接続の確立にはかなりの費用がかかるため（文字通り数秒）、スケーラビリティを向上させるためにプールを作成しようとしています。

すべてが非常にシンプルで、1つのポイントまで、古い接続をリサイクルします。古いとは、「プールに5分以上使用されていない接続」を意味します。それらをクリーンアップすると、接続先のサーバー上のリソースも解放されます。

5分ごとに起動し、プール内の古い未使用の接続をチェックして、それらを閉じる、ある種のスレッドが必要になります。ただし、Googleから理解したように、ASP.NETと長時間実行されるスレッドは混在していません。

プロセス全体が終了することを恐れていません。そうすると、プールもクリーンアップされるためです（デストラクタとすべて）。私が恐れているのは、アプリケーションが終了する前にクリーンアップスレッドが終了する可能性があることです（そして、プールはクリーナーなしで残されます）。または、その逆です。クリーニングスレッドがアプリケーションの終了をブロックします。

これを正しく実装する方法は？

何人かの人々はこれをする外部サービスを提案しました。なぜこれが実現できないのかがわかるように、「ミステリオスサービス」について詳しく説明します。

「不思議なサービス」は、私の会社が10年以上にわたって作成したアプリケーションの巨大なものです。これは、データにMSSQLまたはOracleを使用するDelphiアカウンティングアプリケーションです。他にサーバーはありません。

最近（数年前のように）、外部アプリケーションが通信に使用できるインターフェースも取得しました。これは基本的に同じアプリケーションであるWindowsコンソールアプリケーションですが、GUIの代わりにソケットをリッスンし、ある種のDelphiシリアル化を使用してデータをやり取りします。

クライアント側には、このバイナリデータストリームを解析して.NETのビジネスレイヤーを模倣する.DLL（Javaで記述され、後でJ＃でコンパイルするように変更されます）があります。つまり、Delphiの元のアプリケーションと同じビジネスクラス（700以上）をすべて取得します。またはそれにかなり近いもの（アプリケーション自体には3000を超えるクラスがあると思います）。そして、私はそれらを使用して、必要なビジネスロジックを実行する必要があります。私のすべての呼び出しは実際のアプリケーションに転送され、実際のアプリケーションが作業を行います。

サーバーには多くの奇妙なビジネスロジックがあり、それらを複製して維持する必要があるため、MSSQL / Oracle DBに直接接続できません（アプリケーションは常に開発されています）。クライアントの.DLLを再作成することはできません。これは、時間がかかりすぎ、プロトコルがとにかくほぼ同じ結果を指示するためです。そこにある700以上のクラスをすべてラップする必要があるため、ラッパーを作成することはできません。

言い換えれば、私はビジネス層を管理していません。それはそのままです（そして実際には何人かの人々がそれで働き続けるのではなくやめました）。私はただ物事を最大限に活用しようとしています。

クリスと他の好奇心旺盛な人々に。

ものを使用するためのコードは次のようなものです：

ConnectionType con = new ConnectionType;
con.OpenConnection("server", "port", "username", "password");
BLObjectNumber234 obj = (BLObjectNumber234)con.GetBLObject("BLObjectNumber234");
obj.GetByPK(123);
// Do some stuff with obj's properties and methods
// that are different for each BLObject type

これらのBLオブジェクトはかなり無計画です。それらはすべてシングルトンです-への呼び出しはcon.GetBLObject常に同じインスタンスを返します。ほとんどのデータはDataTable特別なメソッドを呼び出すことによって取得されますが、かなりの数がプロパティにもあります。いくつかは、bizzareの文書化されていない定数を使用して特別なメソッドを呼び出す必要があります。BLオブジェクトインスタンス以外のプロパティもあり（それらもシングルトンかどうかはわかりませんが、そうではないと思います）、データを入力するために特別なコードが必要です。

全体として、私はこのシステムを「パッチウェア」と呼んでいます。これは、100万のパッチと回避策によって作成されたようで、当時最も便利だった方法ですべてがくっついているためです。

バンプ？（とにかくここでどのようにぶつかりますか？）

4

3 に答える 3

1

すべてのクラスと関数をラッパー化する必要はなく、実行する必要のあるアクションだけをラップする必要があります。したがって、一部のデータをフェッチするメソッドと一部のデータを更新するメソッドが必要になる場合があります。これは、必要に応じてさまざまな関数への一連の呼び出しとしてサービスに変換されます。フロントエンドロジックが簡素化されるため、これによりWebサイトの将来のリリースが簡素化されます。

さて、この質問へのあなた自身の追加に対処するためだけに-私はあなたが「ラッパー」の意味にあまりにも夢中になっていると思います。とにかく、すでに何らかのラッパーを実行していることを願っています。あるいは、これを想定するのをやめて、直接質問する必要があります。このサービスをasp.netページの背後にあるコードから直接呼び出しているのか、それとも別のビルドを行っているのか。フロントエンドとサービス間の通信を処理するクラス？現在使用しているアーキテクチャを確立したら、このロジックを別のサービスに移動できるかどうかを確認します（そして、WCFが提供できるメリットを享受します）。

于 2008-11-27T13:46:06.467 に答える
1

Chris に同意します。すべてのビジネス ロジック (すべての不可解なビジネス オブジェクトと通信するコード) を Web (プレゼンテーション) レイヤーよりも別のレイヤーに配置する方がはるかに適切です。

これにより、アプリケーション設計のスケーラビリティが大幅に向上し、プーリング、スレッド化、およびその他のスケーラビリティ関連のタスクをはるかに簡単に実行できるようになります。

Web とビジネス層の間の通信に WCF を使用することを選択した場合 (同じマシン上にある場合は名前パイプを使用します)、クリーンでスケーラブルでパフォーマンスの高いアーキテクチャを手に入れることができます。

于 2008-11-27T14:16:00.777 に答える
0

呼び出そうとしているサービスをラッパー化するWCFサービスを作成し、WCFサービスアプリケーションを介してのみこの不思議なサービスと通信することができます。

WCFには、プーリングとクリーンアップを処理するためのさまざまなモデルがあります。

于 2008-11-27T13:07:09.417 に答える