主なアプローチは 2 つあります。1 つ目は、多くの利用可能なフレームワーク (Struts、Spring、Java Server Faces など) の 1 つを利用して、クライアントを HTML/JavaScript で書き直すことです。ただし、特に Swing アプリケーションよりも Web アプリケーションを好む場合や、ユーザー インターフェイスが非常に複雑な場合を除きます。ビジネスロジックの上に薄いレイヤーを配置する場合、これはコストのかかるアプローチです。
2 番目の方法では、ユーザー インターフェイスとデータベースの間にサーバーを挿入します。オープン ソースの Java ベースのサーバーには、Jetty、Tomcat、Spring、JBoss/WildFly、および GlassFish が含まれます。
ユーザー インターフェイス、ビジネス ロジック、およびデータ アクセス コードが別々のレイヤーに属するようにコードがレイヤーで構成されている場合、2 層システムから 3 層システムへの変換は、その機能を理解すれば簡単です。選択した中間層サーバーとその使用方法。
基本的なテクニックは次のとおりです。
- すべてのユーザー インターフェイス/Swing コードはクライアントに残ります。
- すべてのビジネス ロジックが中間層サーバーに移動します。クライアントは、リモート プロトコルを使用してビジネス ロジックと通信します。
- すべてのデータ アクセス コードはサーバーに移動されます。
依存性注入は、このリファクタリングを段階的に実行するのに役立ち、必要に応じて 2 層モードまたは 3 層モードで作業することを選択することもできます。
2 層アプリケーションと 3 層アプリケーションの主な違いは次の 3 つです。
- セキュリティ - システムへの新しいアクセス ポイントがあります。データベースへのアクセス権に注意する必要があります。すべてを実行できるサーバー ユーザーが 1 人いるか、または各ユーザーが独自の接続資格情報を使用する必要があるか。また、サーバーを正しく保護し、中間層 API にセキュリティ ホールを追加しないように注意する必要があります。
- リモート アクセス - 以前は同じプロセス内で行われていた一部のメソッド呼び出しが、ネットワーク経由で行われるようになりました。一般に、サーバー API は、ローカル API よりもきめ細かい操作をサポートする必要がなく、引数および戻り値として送信されるデータの量も管理する必要がある場合があります。
- アプリケーションの構造がより重要になります。コードは必ずしも大きく異なるわけではありませんが、異なるレイヤーに編成する必要があります。