私は、テレリック コントロール (v2009 q2) を備えた asp.net を使用して、データ駆動型アプリケーションをプログラミングしています。BLL という名前のクラスがあります。これには、ID をパラメーターとして受け取るさまざまなオブジェクトを返す静的クラス (ほとんどのみ) が含まれています。通常、オブジェクトのグループをリストとして返します。
私の質問は、常に静的を使用して、これに建築上の欠陥があるかということです。ビジネスレイヤーとデータアクセスレイヤーを別々のプロジェクトとして作成している人がいることを私は知っています。それがプロジェクトであることの利点は何ですか？だから私はより多くの機能を追加することができます。
前もって感謝します
エントリの方法として静的メソッドを使用することは、特に大きな問題ではありません。静的定義では状態情報を保存または分離できない場合があるため、状態を保存する必要がある作業領域があるかどうかに大きく依存します。幸いなことに、静的宣言を使用してからメンバー宣言に戻ることは、通常、その逆よりも苦痛が少なくなります。そのようなメソッドから返されたアイテムが状態に対して単独で責任を負う場合、これが問題として発生することさえないかもしれません。
個別のライブラリ/プロジェクトは、作業単位を分割するのに役立ちます。Dave Swersky が述べたように、特にマルチスレッド アプリでは、静的メンバー変数に癖が見られる場合がありますが、すべてを異なるライブラリに分離する必要があるという厳密な要件はありません。
個別のライブラリを使用すると、次の利点も得られます。
ただし、一部の関係者は、大規模なモノリシック ライブラリの方が適していることを発見しました。このシナリオで重要な利点を次に示します。
最後に、ネストされた静的クラスを実装しているように見えることに気付きました。あなたの作品を使用している他の人が、Intellisense または他の環境ショートカットを使用できない環境にいる場合、このセットアップを使用するのが非常に面倒であると感じるかもしれません。代わりに、いくつかのレベルのネストを個別の (またはネストされた) 名前空間に展開することを検討してください。これは、対象のアイテムを宣言するために必要な入力の量を減らすのにも役立ちます。静的なネストされたアイテムが毎回存在する必要がある場合、名前空間宣言は一度だけ存在する必要があるためです。あなたのカウンターパートはこれを気に入るはずです。
BLLとDALが別々のプロジェクト（つまり、別々のアセンブリ）にあるということは、再コンパイルせずに異なるユーザーインターフェイスで使用できることを意味しますが、さらに重要なことは、DLLの境界インターフェイスと依存関係が比較的明確に定義されていることです（ただし、優れたデザインを保証します。少なくとも分離を強制します）。論理的に分離された単一のアセンブリを作成することも可能であるため、必須でも十分でもありません。
静的メソッドとビジネスオブジェクトクラスに関しては、これは異常であり、欠点がある可能性がありますが、レイヤーが分離されているかどうかには実際には影響しません。
別のプロジェクトの利点の1つは、アプリケーションを更新する必要があるがBLLのみを変更する場合、変更を加え、DLLを再コンパイルして、アプリケーションがIISに展開されているbinフォルダーにドロップできることです。全体を再展開する必要はありません。ウェブアプリケーション
アプリケーションがステートレスの場合、すべて静的なメソッド/クラスは問題になりません。ただし、アプリがマルチスレッドで、BLL が読み取りとコミットを行う場合、スレッド セーフの問題が発生する可能性があります。
私の質問は、常に静的を使用して、これに建築上の欠陥があるかということです。
このアプローチの 1 つの欠点は、インターフェイスを静的メソッドに適用できないことです。考えられる回避策はシングルトン パターンを使用することですが、スレッド化の問題に注意する必要があります。
ビジネスレイヤーとデータアクセスレイヤーを別々のプロジェクトとして作成している人がいることを私は知っています。それがプロジェクトであることの利点は何ですか？だから私はより多くの機能を追加することができます。
利点: