1

現在のデザインについてのフィードバックを探していました。

これが現在の様子です

  1. Webアプリ（UI）はBLLレイヤーとBusinessEntitiesレイヤーを参照します
  2. BusinessEntitesレイヤー-インターフェースとクラスが含まれています（プロパティの内部検証が含まれています）
  3. BLL（BusinessEntitiesおよびDALレイヤーを参照）-ほとんどの場合、Create（）Save（）Delete（）などのメソッドを持つ各ビジネスオブジェクトのマネージャーがあります。
  4. DAL（BusinessEntitiesレイヤーを参照）-ビジネスエンティティオブジェクトを作成/追加/更新するDBコマンドがあります。

レイヤーに使用した命名規則についてはよくわかりません。そのため、誰かが私よりも良い提案があれば、喜んで採用します。

また、DALがBusinessEntitiesレイヤーを参照するというアイデアは好きではありませんが、Datasets / DataTablesの代わりにオブジェクトを返す方法は他にありますか？

フィードバックをありがとうございます。

4

1 に答える 1

1

DAL からビジネス層を参照する必要があるという点に関しては、これはおそらく最適ではないことに同意します。下位層はその上位層を認識してはならず、再利用性が低下し、余分な/潜在的に循環する依存関係が追加されます。

(現在の設計のように) DAL がファクトリのように機能するのではなく、DAL クラスを使用してビジネス エンティティを「自分自身で埋め」、独自の永続化操作を実行することを検討しましたか? そうすれば、DAL はデータベースのより直接的な表現になり、ビジネス エンティティには、それ自体を適切に埋めて永続化するために必要な (ビジネス) ロジックが含まれます。

また、指定した「BLL」レイヤーには、ビジネスロジックが含まれているようには見えません。私には、エンティティの永続化サービス層のように見えます。

したがって、あなたが提案するもののバリエーションは次のようになります。

  1. ビジネス エンティティを参照する Web/UI
  2. BusinessEntities には、ビジネス ロジックを備えたインターフェイスとクラスが含まれています。参照 DataServices レイヤー
  3. DataServices には、データの読み込み、検索、および永続化を行うクラスが含まれています。ビジネス エンティティが生成、消費、処理できるデータ (データ転送オブジェクト) を含む「一般的な」構造を提供できます。DAL を参照します。
  4. テーブルにマップするクラスを提供するだけの DAL。

要件によっては、BusinessEntities と DataServices (元の設計では BLL) を 1 つの層にマージすることを検討します。それらを分割する唯一の理由は、Silverlight のように、クライアント側のビジネス エンティティで非同期データ操作が必要な場合です。

もちろん、これはすべて、特定のシステム要件に関する不完全な知識によるものです。特定のアプリケーションに最適なものを設計する必要があります。幸運を！

于 2009-04-08T17:21:30.843 に答える