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

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

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

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

たとえば、次のようにする代わりに：

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

またはそのようなもの。

Microsoft Patterns＆Practicesの図が気に入っています。そして、「絵は千の言葉に値する」という格言を信じています。

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

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

つまり、コントローラーにはビューとユーザーインタラクションを処理する追加の機能があり、1つの目的のみでオブジェクトを作成する必要があるため、「ビジネスロジック」はコントローラーに存在しないはずです。

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

サービスレイヤーによる検証を示す、Stephen Waltherによるこの素晴らしいチュートリアルを確認できます。

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

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

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

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

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

モデルとは？さて、それは良い質問です。マイクロソフトのパターンと実践の記事をご覧ください（優れた検索については、AlejandroRのkudos）。ここには、モデルの3つのカテゴリがあります。

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

もちろん、MVCはさまざまな種類のパラダイムです。ここで説明するのは、MVCが最上位層のみを占めることです。ウィキペディアでこの記事をご覧ください。

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

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