1

私たちが知っているように、ほぼすべての複雑なアーキテクチャには複数のレイヤーが含まれています。管理システムでは、あまり考えなくても、データ アクセス層、ビジネス ロジック層、およびプレゼンテーション層を簡単に思いつくことができます。複数のレイヤーを作成する方法について明確な原則があるかどうかを知りたいです。PS: 管理システムに限ったことではありません。

4

3 に答える 3

1

私は、主な階層化の原則は関心の分離であると信じています。それは実際にはオブジェクト指向設計に縛られていませんが、ソフトウェアエンジニアリング全体です（ウィキペディアの記事は例としてスタックプロトコルを提供しています）。

したがって、通常、機能領域（F1、F2、F3）を見つけて、そのうちの1つだけを実行するコンポーネントを設計するように強制します。「Xとは何ですか？」「F1、F2、F3」と答えた場合、XをX1、X2、X3に分割します。これらは、それぞれ1つの機能を実行しますが、それはうまくいきます。

簡単で誇張された例

class SomeBusinessObject //Business logic, as we think
{
    bool HasAccess(User loggedInUser)
    {
           /* two lines below are clearly from DataAccess layer */
           string q = "select 1 from user_roles where id={0} and isadmin=1";
           bool hasAccess = DataAccess.Execure(q).Rows > 0;
           if(!hasAccess)
           {
                /* message pre-formatting is Presentation layer concern */
                var msg = string.Format("<b>You don't have access</b>";
                throw new SecurityException(msg);
           }
           return true;
    }
}

上記のサンプルでは、​​BLクラスはデータモデルとデータアクセスの詳細について知っている必要があります。また、htmlベースのUI用にメッセージを事前にフォーマットしようとします。したがって、おそらくフォーマットをビューに移動します。SQLクエリの生成をDALに抽出します。

一般に、次のレイヤーがあります。

  1. プレゼンテーション層
    • UIレンダリングレイヤー（通常はビュー）
    • プレゼンテーションロジック（プレゼンター/コントローラー）
  2. サービスレイヤー（比較的小規模なシステムでは省略できます）
  3. ビジネスの論理。それを重ねたい場合は、おそらく次のことを考えることができます。
    • ビジネスルールレイヤー。
    • 検証レイヤー。
    • ビジネスロジック自体。
    • データ変換
    • クエリサービス
  4. データアクセス。2つの層に分けることができます：
    • ビジネスレイヤーにサービスを提供する抽象データアクセス
    • 以下の正確な実装、「DB」レイヤー。

一般に、2つのレイヤー関係ルールがあります。

  1. レイヤーは、下にあるレイヤーとのみ「通信」する必要があります。（たとえば、BLからプレゼンテーションへの依存関係、DALからBLへの依存関係があってはなりません）。
  2. レイヤーはレイヤーを「ジャンプ」してはいけません。（プレゼンテーションはDALと話すべきではありません）。

ただし、実際にはどのレイヤーにもバインドされていない横断的な機能もあります。これは主にロギングやキャッシングなどに当てはまります。セキュリティについて言う人もいますが、レイヤー固有の方法で実行できると確信しています。

お役に立てば幸いです。

于 2011-12-02T10:16:56.580 に答える
1

階層化されたアーキテクチャスタイルは、階層の呼び出しを意味します。別のレイヤーと見なされるものについては、他のレイヤーとの通信パターンを制限する必要があります。レイヤーは、その上のレイヤーに機能を提供し、上のレイヤーからの機能を使用します。純粋な階層化システムでは、層は階層内の1つのステップしか見ることができません（たとえば、TCP / IPプロトコルアーキテクチャ）。

レイヤリングの利点には、緩い結合の増加とさまざまなレイヤの進化可能性が含まれます。レイヤーの主な欠点は、レイテンシーを追加してデータをコピーすることです（レイヤーからレイヤーに渡す）-したがって、新しいレイヤーを決定するときは、緩い結合と追加されたレイテンシーを考慮する必要があります

それに加えて、レイヤーとティアの違い、または常に同じマシン上に存在するレイヤー（レイヤー）と、マシンをまたがる境界を持つレイヤー（ティア）に注意を払う必要があります。レイヤーが分散されている場合は、レイテンシーだけでなく注意を払う必要があるため（分散コンピューティングの落とし穴を参照）、ティアを追加する非常に正当な理由があるはずです。

于 2011-12-02T14:01:58.437 に答える
1

ソフトウェア エンジニアリングでは、システムを設計するときに、特定の設計原則に従う必要があります。これを正しく行うと、レイヤーはほぼ自然に現れます。原則のいくつかは次のとおりです。

  1. オープン/クローズ
  2. 単一の責任
  3. インターフェースの分離
  4. リリース再利用の等価性
  5. 共通の閉鎖

他にもあります。それらについてはオンラインで読むか、Robert Martin による「Agile Software Development, Principles, Patterns, and Practices」という本を入手できます。

これは、本の関連する章へのリンクです。

于 2011-12-01T04:40:01.053 に答える