4

BLL と DAL の関係について少し混乱しています。BLL は依存性注入を介して DAL をカプセル化する必要がありますか? それとも、BLL はドメイン オブジェクトに対してのみ動作し、DAL は個別に保存/更新する必要がありますか?

たとえば、(典型的な MVC アプリで) 注文を更新して在庫を更新する必要がある Cancel Order 関数を想像してみてください。私の行動は次のようになりますか？

public ActionResult CancelOrder (Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    _orderService.CancelOrder(order, stockItem);
    orderRepository.Update(order);
    orderRepository.Update(stock);
    Return View();
}

または、次のようにする必要がありますか？

public ActionResult CancelOrder (Guid orderId) {
    _orderService.CancelOrder(orderId);
    Return View();
}

(within OrderService)
public void CancelOrder(Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    order.Cancelled = true;
    stockItem.AmountInStock = stockItem.AmountInStock + order.Amount;
    orderRepository.Update(order);
    orderRepository.Update(stock);
}

このオプションを使用すると、データ アクセスを含むすべてが BLL によって処理されます。リポジトリは密結合を避けるために注入されます。エンティティの取得は_orderService.GetOrder(orderId);、リポジトリに直接行くのと同じように行われます。

時間があまりないので、例が粗雑ですみません。私が書いたことのどれかが少しでも理にかなっていますか、それとも私は荒野にいますか?

4

4 に答える 4

5

ビジネスロジックをコントローラーに埋め込む最初のオプションではないことは間違いありません。問題は、コントローラがデータ オブジェクト自体にアクセスすることではなく、ビジネス ルールによって規定された手順に従う必要があることです。この手順は、コントローラーにはありません。

したがって、2 番目のオプションを使用するか、場合によってはCancelのメソッドを作成する必要がありOrderます。すでに同様のコードを書いている場合は、一貫性を保ってください。

于 2012-09-05T10:08:14.977 に答える
1

懸念事項の分離を考えてみてください。コントローラーは PRESENTATION パターンである MVC パターンに由来するため、コントローラーにはビジネス ロジックではなく、プレゼンテーション ロジックをサポートするプレゼンテーション レイヤーが含まれている必要があります。

ビジネス ロジックはドメイン エンティティに配置する必要があることは合意されていますが、リポジトリ間のコーディネーターとしての役割を果たすアプリケーション ロジックもいくつかあります。そのため、サービス レイヤーが途中でダウンしています。

したがって、オプション 2 は邪魔になるはずです。

于 2012-09-05T10:19:19.200 に答える
1

あなたは本当にここで2つの質問をしています:

コントローラーとビジネスレイヤーには何が必要ですか?

=> 最初のスニペットのコードは、アプリケーション レイヤー サービスに対する適切なレベルの責任であると考える傾向があります (この 2 つが似ていることを認めれば、結果的にコントローラーに対しても責任が生じます。この 2 つは、この時期について多くの議論があります)。リポジトリから を取得しOrderてキャンセル操作後に保存することは、純粋なビジネス ロジックとは思えません。それは、周囲のトランザクション/作業単位と、ユースケースの配管に関係しています。

変更したいことは 1 つだけです。トランザクションの影響を受けるすべてのエンティティへの変更を一度に保存するようにしてください。操作の最後に変更される可能性のあるすべてのエンティティを手動で更新する必要がある場合、それは大きな苦痛になり、コントローラーを不必要に汚染します。一度にすべての変更を保持し、リポジトリ内のすべての Update() メソッドを削除する作業単位システムを作成します (または既存の実装を使用します)。

それ以外では、Jon が示唆しているように、メソッドをOrder含む豊富なドメイン オブジェクトがサービスよりも望ましいと考えていますが、これは別の議論です。Cancel()

BLL と DAL の間にはどのような関係が必要ですか?

=> BLL は DAL と密接に結合されるべきではなく、最も中心的なレイヤーとして、外側のレイヤーを直接参照することは想定されていません。このようにして、BLL を別のアプリケーションや別の DAL などで簡単に再利用できます。

ただし、一部のビジネス オブジェクトは、まだ参照を持っていない他のオブジェクトに直接アクセスする必要がある場合があります。これは基本的に、データベースから取得することを意味します。つまり、BLL の一部の操作では、リポジトリと通信する必要があります。したがって、私は常にリポジトリインターフェイスを BLL に配置しますが、それらの実装は DAL に存在し、実行時に BLL に挿入されます。

その結果、BLL は DAL に疎結合されます。中立的なオブジェクトのコレクションのように見えるファサード (リポジトリ) のみを操作し、データの保存方法やハイドレート方法などを認識しないという点で、永続性を無視したままです。

于 2012-09-05T13:49:30.953 に答える
0

BLL は、アプリケーション用に作成したビジネス オブジェクトに作用する必要があります。理想的には、データベースおよび関連する操作を認識しないようにする必要があります。疎結合を維持したい場合は、依存性注入を利用して DAL からメソッドを呼び出します。

于 2012-09-05T10:07:30.897 に答える