セットアップ ファイルとして配布されている vb6-mysql クライアント サーバー デスクトップ アプリケーションがあります。
データベース操作だけでなく、すべての論理操作に DLL を使用します。EXE と DLL は、サーバーとクライアント マシンにインストールされます。データベースがそのマシンに存在することのみを意味するサーバーと言うとき、EXEまたはDLLに他の違いはありません。
クライアント マシンから接続すると、すべてのデータベース操作が DLL で実行されるため、パフォーマンスが低下します。すべてのロジックをデータベースに変更することは現在不可能です。
DLL をサーバー マシンにのみ格納し、クライアント マシンでも同じ DLL を使用して、データベース接続が常にサーバー自体から行われるようにすることは可能ですか?
DLL を Windows サービスに変換することは、これに対する可能な解決策ですか?
n 層アプリケーション開発を再発見しようとしているようです。
LAN 内でVB6 を使用してこれを行う通常の方法は、DLL の代わりに ActiveX EXE を作成して、DCOM を使用できるようにすることです。ただし、DCOM は、インターネット経由で公開したいものではありません。
このような場合は、HTTP や HTTPS などの一般的に開かれているポート プロトコルを使用するのがより一般的です。ほとんどすべての人が、アウトバウンド HTTP および HTTPS 接続を許可するファイアウォール設定を持っており、主要な Web サーバーのほとんどは、インターネットにさらされても安全になるように定期的に強化されています。
VB6 でこれを行う従来の方法は、IIS を使用してリモート データ サービスをホストすることでした。これは、プログラムが面倒な詳細を処理しない「隠れた」Web サービスの形式を使用します。ただし、これは非推奨のアプローチであり、現在、IIS と RDS コンポーネントの構成は、既定でハードにロックされているため、面倒な作業になる可能性があります。
これにより、非推奨の SOAP ツールキットや、PocketSOAP スイートなどのサード パーティ製ツールが残ります。または、独自のツールを開発することもできます。
これを最初から行うのは少し手間がかかる場合がありますが、より柔軟で、SOAP の代わりに REST を使用できるため、それ自体に利点があります。VB6 で (CGI などを介して) 動作する任意の Web サーバーを使用できます。
正当化するのが最も難しいアプローチは、表面的には最も単純に見えるかもしれません: TCP を介して独自のプロトコルを作成し、Windows サービスを記述します。これはすべての中で最も柔軟ですが、他のオプションよりも手間がかかる可能性があり、作成して安全に保つことは自分で行う必要があります。クライアントの場所やローカル ファイアウォール ポリシーの内容によっては、おそらくファイアウォールの問題にも直面するでしょう。
DCOM に頼ることができたときは、セキュリティ構成の問題を除けば、問題は比較的小さなものでした。絵の中にインターネットがあると、それはまったく別の話です。
これは本当に何気なく着手するものではありません。データベースがインターネットにさらされても安全であると仮定することは単純であり、再考する必要があります。