n層アーキテクチャのフィードバックが必要

Question

私は自分のウェブサイトを、stackoverflowのように、少し技術的な借金で始めました。契約開発者であるため、私は多くの場所にいて、この結果を達成するための多くの異なる方法を見てきましたが、私が行く方法は..

プレゼンテーション（ウェブ）

ビジネスレイヤー（旧式のエンティティクラスとBLレイヤー）

データ層（ストアドクラスを介したSQL ServerへのDAクラス）

私の質問は、主にビジネス層に関するものです。現在、Entity名前空間とBusinessLogic名前空間があります。

BLには、DAおよびエンティティへの参照があります。 エンティティにはDAへの参照があります （DAはBLまたはエンティティを「認識しない」）

BL内でデータをエンティティに変えるというすべての混乱、つまりビジネスロジックが本当に発生するようにしたいのです。ただし、必要に応じてエンティティがBLにアクセスできるようにして、エンティティのDLへの参照を削除します。

そう...

は「間違っています」 BLとEntityオブジェクトを同じ名前空間内に配置して、それらが連携して動作するようにしますか？

本質的に、私は従業員のようなエンティティオブジェクト（古典的な例、え？）を持って、従業員が持っているしようとしています

public Hashtable[] SubordinateEmployees

この従業員に報告する他の従業員オブジェクトのハッシュテーブルを返すプロパティ。しかし、必要になるまでロードしたくありません。そのため、ほとんどの従業員はプロパティにアクセスできませんが、アクセスすると、DAを呼び出すBLへの呼び出しで自己読み込みします。

質問は理にかなっていますか

もしそうなら、私の解決策はありますか？

事前に感謝します！

Answer 1

あなたの例が表すような状況に対処する通常の方法は、ファサードです。 Employeeオブジェクトから下位の従業員を取得しようとする代わりに、ビジネスロジックの呼び出しを使用して取得します。

hashtable = BL.GetSubordinateEmployees(supervisor);

そのようにして、部下への単一のアクセスポイントがあり、データレイヤーにアクセスしてエンティティを作成するもの（BL）が1つだけあります。

Answer 2

これについて考えるより良い方法を紹介できるかどうか見てみましょう

データアクセス（SQLサーバー、mysql、フラットxmlファイルなど）があります。これらはすべて抽象化する必要があります。レイヤー違反のあるデータをどのように取得しているかは、他の誰もが知っています。 DALが他の何かを使用する場合、データを取得すると、レイヤー違反が発生します。次に、ビジネスレイヤーが使用するIDALなどのデータアクセスインターフェイスを実装します。これは、レイヤーを強制的に分離してコードをテスト可能にするために非常に重要です。

データエンティティは、DAL名前空間に配置するか、独自の名前を付けて、独自の力で分離することができます。データエンティティはバカなオブジェクトであり、ロジックをほとんどまたはまったく含まず、自分自身と持っているデータのみを認識している必要があります。ビジネスロジック、データアクセスロジック、またはUIロジックは含まれません。もしそうなら、レイヤー違反があります。データエンティティの唯一の機能は、データを保持し、あるレイヤーから次のレイヤーに渡すことです。

Bizレイヤーは、ファクトリー、IOCコンテナー、またはその他の具象型で失敗するすべてのインスタンスを作成する前に説明したIDALのようなデータアクセスインターフェイスを実装しますが、テスト用に変更できるようにセッタープロパティを追加します。 Bizレイヤーはビジネスロジックのみを処理し、データの送信元または送信先を知らず、気にしません。ビジネスルールに準拠するためにデータを操作することだけを考慮します。これには、日付の検証、フィルタリングが含まれます必要なデータをDALに伝え、DALにその取得方法を見つけさせます）。基本的に、BIZはUI関連でもデータ取得関連でもないすべてのロジックを処理します。 DALと同様に、Bizは同じ理由でインターフェースを実装する必要があります。

UIレイヤーは、Bizレイヤーが同じ理由でDALにアクセスするのと同じ方法で、Bizレイヤーにアクセスします。 UIレイヤーが気にするのは、データを表示し、ユーザーからデータを取得することだけです。 IUレイヤーは、ビジネスルールについて何も知らない必要があります。ただし、データエンティティの設定に必要なデータ検証は例外です。

このアーキテクチャの利点は、関心の分離を強制することで、テスト、柔軟性、および保守が容易になることです。今日、Webサイトを構築していますが、明日、他の人がWebサービスを統合できるようにしたい場合は、BIZのバグを修正する必要があるときに、IBIZインターフェイスを実装するWebサービスを作成するだけです。レイヤー、それはあなたのウェブサイトとウェブサービスの両方ですでに修正されています。

これを次のレベルに引き上げると、大量の大量処理を実行しており、これを処理するためにより強力なサーバーが必要であるため、WCFのラッパーであるIDalおよびIBIZインターフェイスを実装するだけです。サーバー間の通信を処理します。アプリケーションは複数のサーバーに分散され、コードを変更する必要はありませんでした。