ASP.NET MVC-コントローラーにビジネスロジックが存在する必要がありますか？

Question

Derik Whitakerが

役に立ちましたか？

送信

解決

ビジネスロジックは実際にモデルに含まれている必要があります。脂肪モデル、スキニーコントローラーを目指してください。

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

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);
    }
}

またはそのようなもの。

Answer 1

ビジネスロジックは実際にモデルに含まれている必要があります。脂肪モデル、スキニーコントローラーを目指してください。

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

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);
    }
}

またはそのようなもの。

Answer 2

Microsoftパターン＆amp;プラクティス。そして、「写真は千の言葉に値する」という格言を信じています。

Answer 3

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

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

つまり、簡単な答えは、「ビジネスロジック」ということです。コントローラーにはビューとユーザーインタラクションを処理する機能が追加されており、1つの目的だけでオブジェクトを作成するため、コントローラーに実際に存在するべきではありません。

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

Answer 4

サービス層による検証。

  

検証を移動する方法を学ぶ   コントローラーアクションのロジック   そして別のサービス層に。に   このチュートリアル、Stephen Walther   シャープを維持する方法を説明します   分離による懸念の分離   あなたのサービス層   コントローラー層。

Answer 5

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

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

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

では、ビジネスロジックをどこに配置しますか？モデル内。

モデルとは？これはいい質問です。 Microsoft Patterns and Practicesの記事（優れた検索結果についてはAlejandroRに感謝します）を参照してください。ここには、モデルの3つのカテゴリがあります：

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

もちろん、MVCはさまざまな種類のパラダイムです。ここで説明するのは、MVCが最上層のみを占有していることです。 Wikipediaのこの記事

  

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

Answer 6

依存関係インジェクターを使用すると、ビジネスロジックがそれらに移動するため、きちんとしたクリーンなコントローラーが得られます。