99

Derik Whitakerが数日前に記事を投稿しましたが、これは私がしばらくの間興味を持っていたポイントに達しました。ビジネスロジックはコントローラーに存在する必要がありますか？

これまでに見たすべてのASP.NETMVCデモは、リポジトリアクセスとビジネスロジックをコントローラーに配置しました。そこにも検証を投げかける人もいます。これにより、コントローラーがかなり大きく肥大化します。これは本当にMVCフレームワークを使用する方法ですか？これは、多くの重複したコードとロジックがさまざまなコントローラーに分散することになると思われます。

4

6 に答える 6

75

ビジネスロジックは実際にモデルに含まれている必要があります。あなたは太ったモデル、細いコントローラーを目指しているべきです。

たとえば、次の代わりに：

public interface IOrderService{
    int CalculateTotal(Order order);
}

私はむしろ持っていると思います：

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

これは、税金が外部サービスによって計算されることを前提としており、モデルが外部サービスへのインターフェースについて知っている必要があります。

これにより、コントローラーは次のようになります。

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

またはそのようなもの。

于 2008-10-24T21:00:17.017 に答える
65

Microsoft Patterns & Practicesが提示する図が気に入っています。そして私は、「百聞は一見に如かず」という格言を信じています。

図は、MVC とビジネス サービス レイヤーのアーキテクチャを示しています。

于 2012-07-17T21:17:53.143 に答える
14

これは興味深い質問です。

「ビジネス ロジック」を完全にモデルに配置するという意味で、多数のサンプル MVC アプリケーションが実際に MVC パラダイムに従っていないことは興味深いことだと思います。Martin Fowler は、MVC はギャング オブ フォーの意味でのパターンではないことを指摘しています。むしろ、おもちゃのアプリを超えたものを作成する場合、プログラマーがパターンを追加する必要があるのはパラダイムです。

つまり、簡単に言えば、「ビジネス ロジック」は実際にはコントローラーに存在するべきではありません。コントローラーには、ビューとユーザーの対話を処理する追加機能があり、目的が 1 つだけのオブジェクトを作成する必要があるからです。

より長い答えは、コントローラーからモデルにロジックを移動する前に、モデル レイヤーの設計を検討する必要があるということです。おそらく、REST を使用してすべてのアプリ ロジックを処理できます。その場合、モデルの設計はかなり明確になるはずです。そうでない場合は、モデルが肥大化するのを防ぐためにどのようなアプローチを使用するかを知っておく必要があります。

于 2009-01-19T20:04:51.700 に答える
13

この素晴らしいチュートリアルは、サービスレイヤーを使用した検証を示すStephenWaltherによるものです。

検証ロジックをコントローラーアクションから別のサービスレイヤーに移動する方法を学びます。このチュートリアルでは、Stephen Waltherが、サービスレイヤーをコントローラーレイヤーから分離することにより、関心の分離を明確に維持する方法について説明します。

于 2011-04-17T22:10:16.633 に答える
9

ビジネス ロジックをコントローラーに含めないでください。コントローラーは可能な限り細くする必要があり、理想的にはパターンに従います。

  1. ドメイン エンティティを検索
  2. ドメイン エンティティに作用する
  3. 結果を表示/返すためのデータを準備する

さらに、コントローラにはいくつかのアプリケーション ロジックを含めることができます。

では、ビジネス ロジックをどこに置くのでしょうか。モデルで。

モデルとは？これは良い質問です。Microsoft Patterns and Practices の記事を参照してください(すばらしい発見をした AlejandroR に感謝します)。ここには、モデルの 3 つのカテゴリがあります。

  • View Model : これは単純なデータ バッグであり、ビューとの間でデータをやり取りするための最小限のロジックがあり、基本的なフィールド検証が含まれています。
  • ドメイン モデル: ビジネス ロジックを備えたファット モデルで、単一または複数のデータ エンティティで動作します (つまり、エンティティ B に対するアクションではなく、特定の状態のエンティティ A)。
  • データ モデル: ストレージ対応モデル、単一のエンティティ内に含まれるロジックは、そのエンティティのみに関連します (つまり、フィールド a の場合、フィールド b の場合)

もちろん、MVC はさまざまな種類のパラダイムです。ここで説明するのは、最上位レイヤーのみを占有する MVC です。ウィキペディアのこの記事を参照してください。

現在、MVC と同様のモデル ビュー プレゼンター (MVP) は、大規模システムのプレゼンテーション レイヤーにのみ適用される関心の分離設計パターンです。単純なシナリオでは、MVC はシステムの主要な設計を表し、データベースに直接到達します。ただし、ほとんどのシナリオでは、MVC のコントローラーとモデルは、サービスまたはデータ レイヤー/層のいずれかに緩やかに依存しています。これはすべて、クライアントサーバーアーキテクチャに関するものです

于 2013-08-28T11:01:46.797 に答える