かなり標準的な Web/サービス/データ アクセス レイヤード デザインを使用して、楽しみ/学習用の小さな Web サイトを構築しています。
サービス レイヤー/データ アクセス レイヤー クラスのインスタンスを常に作成する必要がないように、それらのメソッドをすべて静的にしました。ローカル変数などを使用し、リソースを共有しないため、同時実行の問題は発生しないはずです (現時点では、これについては十分に単純です)。
私が見る限り、これに対する唯一のトレードオフは、実際には真のオブジェクト指向アプローチに従っていないということですが、それでもコードをよりクリーンに保ちます。
これが実行可能なアプローチではない理由はありますか? 後でどのような問題が発生する可能性がありますか？必要に応じてサービスおよびデータ層クラスのインスタンスを返すことができる「ファクトリ」クラスを用意した方がよいでしょうか?
あなたがそれを説明する方法、これはそれ自体「間違った」アプローチではありませんが、あなたが回避しようとしている問題は実際にはわかりません。サーバーの起動時にこれらのビジネス オブジェクトの単一のインスタンスを作成し、必要に応じてそれらをサーブレットに渡すことはできませんか?
OO を窓の外に放り出す準備ができている場合は、Singleton パターンもチェックしてみてください。
遊園地の乗り物に「手足は常に乗り物に入れておいてください」とある乗り物を知っていますか？そうしないと、ライドがもっと楽しくなることがわかります。唯一の本当のトレードオフは、常に乗車中に手足を離さない真のアプローチに従っていないことです。
ポイントはこれです - 手足を乗り物の中に入れておく理由があるのと同じように、「真のオブジェクト指向アプローチ」に従うべき理由があります - どこでも出血し始めるまではとても楽しいです.
短所:
次のいずれかの方法で、非静的ビジネス/データ アクセス レイヤー クラスを使用することをお勧めします。
アプリケーションに接続された各ユーザー/セッションは独自のスレッドで実行されることに注意してください。つまり、Web アプリケーションは本質的にマルチスレッドです。
私はあなたのデザインの利点をあまり見ていないし、うまくいかないことがたくさんあります. おそらく、コード行を節約していますか？あなたのアプローチにはいくつかの欠点があります：
コードを 1 行省略しただけで何かが得られるとは思えません。
これは実際には「OO 設計」の問題ではなく、より適切な問題です。なぜ、そのような手続き的な方法で Java を使用しているのですか? 確かに、この種の設計には PHP の方が適しています (実際、コンパイルしてデプロイする必要がないため、時間を節約できます)。
ビジネスレイヤーを非静的にするだけです。アプリケーションの保守、変更、進化が非常に簡単になります。
このタイプのアーキテクチャでは、オブジェクトの単体テストが難しい場合があります。たとえば、静的データ アクセス レイヤーを参照するビジネス オブジェクトのレイヤーがある場合、モック データ アクセス オブジェクトを簡単に使用できないため、ビジネス レイヤーのテストが困難になる可能性があります。つまり、ビジネス レイヤーをテストする場合、データベースに不要な変更を加える可能性があるため、データ アクセス レイヤーで「実際の」メソッドを使用したくないでしょう。データ アクセス レイヤーが静的でない場合は、テスト目的でモック データ アクセス オブジェクトをビジネス レイヤーに提供できます。
複数のユーザーがいるすべての静的メソッドで同時実行の問題が発生すると思います。Web レイヤーは、同時ユーザーをスレッド化します。すべての静的メソッドでこれを処理できますか? おそらく、単一のファイルでリクエストをキューに入れると、常にロックされるのではないでしょうか? よくわかりませんが、あなたのアイデアを試したことはありません。