Java Web アプリケーションの静的レイヤー

Question

私は、かなり標準的な Web/サービス/データ アクセスのレイヤード デザインを使用して、楽しみ/学習用の小さな Web サイトを構築しています。

サービス層/データ アクセス層クラスのインスタンスを常に作成する手間を省くために、それらのメソッドをすべて静的にしました。ローカル変数などを使用し、リソースを共有しないため、同時実行の問題が発生するはずはありません（現時点では物事は十分に単純です）。

私が知る限り、これによる唯一のトレードオフは、実際には真の OO アプローチに従っていないことですが、それでも、コードがはるかにクリーンに保たれます。

これが実行可能なアプローチではない理由はありますか?後々どのような問題が発生する可能性がありますか？必要に応じてサービスおよびデータ層クラスのインスタンスを返すことができる「ファクトリー」クラスを用意した方がよいでしょうか?

Answer 1

短所:

• テスト対象となるモック データ アクセス/ビジネス ロジック オブジェクトを作成できないため、単体テストを作成することもできません。
• 異なるスレッドが静的コードに同時にアクセスしようとすると、同時実行性の問題が発生します。また、同期された静的メソッドを使用すると、静的メソッドを使用するためにスレッドがキューに入れられることになります。
• インスタンス変数は使用できなくなります。コードが複雑になると、これが制限となります。
• 必要に応じて、ビジネス層やデータ アクセス層の要素を置き換えるのはさらに困難になります。
• この方法でアプリケーションを作成する場合は、PHP など、この方法で動作するように設計された言語を使用することをお勧めします。

次のいずれかの方法で、非静的ビジネス/データ アクセス層クラスを選択することをお勧めします。

• シングルトン パターンを使用する (各クラスの単一のインスタンスを作成し、スレッド間で共有する)...
• または、必要に応じて各スレッドでクラスのインスタンスを作成します。

アプリケーションに接続されている各ユーザー/セッションは独自のスレッドで実行されるため、Web アプリケーションは本質的にマルチスレッドであることに注意してください。

Answer 2

遊園地の乗り物で「手足は常に乗り物内に入れてください」と書かれているのをご存知ですか？そうしないほうが、乗り心地はずっと楽しいことがわかりました。唯一の本当のトレードオフは、常に手と足を車内に置いておくという真のアプローチに従っていないことです。

重要なのは、これです。「真の OO アプローチ」に従わなければならない理由があるのと同じように、手と足を乗り物の中に入れておかなければならない理由があります。あちこちから出血し始めるまでは、とても楽しいです。

Answer 3

あなたが説明しているように、これはそれ自体「間違った」アプローチではありませんが、あなたが避けようとしている問題が本当にわかりません。サーバーの起動時にこれらのビジネス オブジェクトの単一インスタンスを作成し、必要に応じてサーブレットに渡すことはできないでしょうか?

OO を窓から投げ出す準備ができている場合は、Singleton パターンもチェックしてみてください。

Answer 4

あなたの設計には利点があまりありませんし、問題が発生する可能性のあることがたくさんあります。コード行を保存しているのではないでしょうか?このアプローチには次のような欠点があります。

• ビジネス ロジックの実装を簡単に置き換えることはできません
• ロジックを複数のメソッドに分割しやすくするためにインスタンス変数を定義することはできません
• マルチスレッドの問題は発生しないというあなたの仮定は、ほぼ間違いなく間違っています
• テストのために簡単にモックすることはできません

コードを 1 行省略したからといって、何かが得られるとは思えません。

これは実際には「OO デザイン」の問題ではなく、むしろ適切性の問題です。なぜそのような手続き的な方法で Java を使用するのでしょうか?確かに、この種の設計には PHP の方が適しています (実際、コンパイルとデプロイの必要がないため、時間を節約できます)。

ビジネス層を非静的にするだけです。これにより、アプリケーションの保守、変更、進化が非常に簡単になります。

Answer 5

このタイプのアーキテクチャでは、オブジェクトの単体テストが困難になる可能性があります。たとえば、静的データ アクセス レイヤーを参照するビジネス オブジェクトのレイヤーがある場合、モック データ アクセス オブジェクトを簡単に使用できないため、ビジネス レイヤーのテストが困難になる可能性があります。つまり、ビジネス層をテストするときは、データベースに望ましくない変更を加える可能性があるため、データ アクセス層で「実際の」メソッドを使用することはおそらく望ましくないでしょう。データ アクセス レイヤーが静的でない場合は、テスト目的でビジネス レイヤーにモック データ アクセス オブジェクトを提供できます。

Answer 6

複数のユーザーがいる場合、すべての静的メソッドで同時実行の問題が発生すると思います。Web レイヤーは同時ユーザーをスレッドアウトします。すべての静的メソッドでこれを処理できますか?おそらくですが、単一のファイルでリクエストをキューに入れると常にロックされるのではありませんか?よくわかりませんが、あなたのアイデアを試したことはありません。