asp.net-mvc - 並べ替えロジックは、モデル、ビュー、またはコントローラーに配置する必要がありますか？

Question

テーブルからエンドユーザーに値を表示するドロップダウンリストがあります。これらの値をアルファベット順に並べ替えてもらいたいのですが。

適切なMVC設計によれば、ソートロジックをどのレイヤーに配置する必要がありますか：モデル、ビュー、またはコントローラー？

編集：LarsHの質問「どのソート順が必要かを決定するコードを意味しますか？それともソートを実行するコードを意味しますか？」に対して、私はもともとどのソート順が必要かを決定するコードを参照していました。

score 62 · Accepted Answer

誰がソート順を制御しますか？

単純なMVC図（ウィキペディアから）

1）データ自体の自然な順序：

注文はモデルの一部であるため、そこに移動する必要があります。「すべてのデータ」を生でプルすると、ソートされた順序でデータが返され、ソート順を選択するためのインターフェースはありません。

2）ユーザーは、データの表示方法を制御する必要があります。

ビューは、コントローラーと対話するインターフェース（昇順/降順の矢印など）を提供し、モデルは、データに対して要求された並べ替えを実行するのに十分なデータを理解します。ただし、（1）の場合とは異なり、データの生のプルは必ずしもソートする必要はありません。

どちらの場合にも、

ビューは、ソートが行われていることを理解していませんが、どのソート方向が選択されているかを表示する機能はありません。そこにロジックを置かないでください。

小さな警告

並べ替え機能は、ある状況下では、純粋にビューに組み込まれる可能性があります（私は手に負えないと考えることができますが、もっとあるかもしれません）。

すべてのデータがすでにビューにあり、並べ替えを行うためにドメイン知識を使用する必要がない「ダム」並べ替え。たとえば、非常に単純な文字列または数値の比較。これは、たとえば、結果が複数のページに分割される可能性が高いWebページの検索結果では不可能です。

score 49 · Accepted Answer

（注：この引用と引用は@dasblinkenlightの回答から引用されていますが、私たちの解釈には同意しません。彼の投稿を読んで、自分で決めてください）。

MVCの説明によると、

コントローラは、関連するビューにコマンドを送信して、モデルのビューの表示を変更できます（たとえば、ドキュメントをスクロールすることによって）。モデルにコマンドを送信して、モデルの状態を更新できます（ドキュメントの編集など）。

並べ替えロジック（たとえば、並べ替えコンパレータ/並べ替えアルゴリズム）は、ビジネスルールと状態データが含まれているため、モデルに属します。モデルデータの並べ替え方法の変更は、「モデルのビューの表示の変更」カテゴリに直接分類されるため、コントローラーは、model.changeSortedState（）メソッドを呼び出して「並べ替えを行う」責任があります。

score 18 · Accepted Answer

MVCの説明によると、

コントローラは、関連するビューにコマンドを送信して、モデルのビューの表示を変更できます（たとえば、ドキュメントをスクロールすることによって）。モデルにコマンドを送信して、モデルの状態を更新できます（ドキュメントの編集など）。

これによると、モデルデータの並べ替え方法を変更すると、「ビューのモデルの表示を変更する」カテゴリに直接分類されるため、並べ替えロジックはコントローラーに属します。

編集：コメントで表明された複数の誤解を明確にするために、「ソートロジック」はソートを実行するコードではありません。ソートを定義するコードです。並べ替えロジックは、個々のアイテムを相互に比較して順序を確立するか（たとえば、のインスタンスを介してIComparator<T>）、または外部システムによる順序付けに使用されるオブジェクトを構築するロジックを含みます（たとえば、のインスタンスを介してIOrderedQueryable<T>）。このロジックは、アプリケーションの「ビジネス」側に関連する知識を必要とするため、コントローラーに属します。並べ替えを実行するだけで十分ですが、実際に実行するコードとは別のものです。それ。ソートするコードは、ビュー、モデル、またはモデルをサポートする永続層（SQLデータベースなど）にある場合があります。

score 10 · Accepted Answer

上記のどれでもない。ソートはビジネスロジックであり、ビジネスロジックは3つのいずれにも属していません。アプリケーション内のすべてのコードがモデル、ビュー、またはコントローラーになるわけではありません。

私がMVCアプリで一般的に行っていることは、すべてのビジネスロジックを実行するサービスレイヤーがあることです。サービスレイヤーのメソッドには、適切な名前のパラメーターを持つクリーンでシンプルなAPIが必要です。次に、コントローラーからこれらのメソッドを呼び出して、モデル内のデータを操作できます。

その意味で、並べ替えは「コントローラー内」ですが、並べ替えを行うコード自体をコントローラーに実装するのではなく、そこからのみ呼び出す必要があります。

score 8 · Accepted Answer

明らかにコントローラーではありません。ビューとモデルにメッセージを送信しますが、実行する作業はできるだけ少なくする必要があります。ユーザーがソートを変更できる場合、そのリクエストはモデルまたはビューに通知することでコントローラーによって処理されます。

それが純粋なビューのものである場合、多分ビュー。アプリケーションが並べ替えなしでも同様に機能する場合、並べ替えは表現の一部にすぎず、ビューに表示されるはずです。

順序付けがドメインの固有の部分である場合は、モデルに含める必要があります。

score 6 · Accepted Answer

ビューは、プレゼンテーションロジックを含むことになっているMVCの一部です。
モデル層は、ビジネスロジックが含まれる場所です。
コントローラは、ユーザー入力に基づいて、両方の状態のみを変更します。

したがって、選択は次のとおりです。これは、ドメインビジネスロジックまたはプレゼンテーションロジックの一部だと思いますか。

適切なMVCModel2または従来のMVCパターンを実装している場合、モデルレイヤーによって提供されるデータの順序付けは、モデルレイヤーへのビューの要求によってトリガーされる必要があります。ビューは順序付けられたデータを要求し、モデルレイヤーがそれを提供します。

ただし、ASP.NET MVCによるMVCパターンの解釈を使用しているため、標準のMVCとは少し異なります。ViewModelインスタンスはモデルレイヤーから順序付けられた情報を要求する必要があります（何らかの理由で、ASP.NETフレームワークはテンプレートを呼び出す必要があると見なします）「ビュー」とビューは「ビューモデル」と呼ばれるべきです..それは奇妙です）。

score 5 · Accepted Answer

私は通常、他の答えと同じようにパターンと一致するようにコントローラーでそれを行います。理由については、以下を参照してください。

私はこれを熟考し、回答と関連資料を読んでいて、実際的に言えば、それはあなたのアプリケーションに依存すると思います：例えば：

中規模/大規模のアプリケーションであるか、複数のUIが関連付けられているか（つまり、Windowsアプリ、Webインターフェイス、電話インターフェイス）。

この場合、おそらくサービスレイヤーを構築してビジネスオブジェクトに配置し、コントローラーから適切なメソッドを呼び出します。

明確に定義された単一のUIWebサイトで、EF Code Firstのようなものを使用していて、サービスレイヤーを作成する予定がないか、作成する予定がなく、すぐに使用できる単純な拡張メソッドを使用してそれを実現することを計画している場合：

この場合、時間/予算に関して実際的に最適であるため、おそらくコントローラーに配置します。

上記と同じであるが、すぐに使用できる拡張メソッドでは実装できない場合。

ここではコントローラーよりも適切であるため、Modelクラスにポップすることを選択することもできます（本当にその単一のタイプにオーダーメイドの場合）。並べ替えを複数のクラスに適用できる場合は、拡張メソッドに実装してから、コントローラーで呼び出します。

総括する：

独断的な答え：サービスレイヤー

実用的な答え：通常、コントローラー

score 3 · Accepted Answer

テーブルからデータを並べ替えることをお勧めします（ドロップダウンリストで役立つほど小さいデータ）は、クエリによって既に並べ替えられたDBから取得する必要があります。私にとって、それはモデルをソートが適用される場所にします。

手作業で並べ替えを行うことにした場合は、モデルまたはコントローラーのいずれかをロジックの優先スポットとして使用することについて、適切な議論があると思います。制限はあなたの特定のフレームワークでしょう。モデル内でのみデータを管理することを好みます。私は（独学で）教えられてきたように、コントローラーを使用してデータ（モデル）とプレゼンテーション（ビュー）を結合します。

score 2 · Accepted Answer

並べ替えはビジネスロジックであるという考えには原則的に同意しますが、それを元の場所に分解すると、「クライアントは製品ページに日付で並べ替えられた画像を表示したい」という結果になるため、次のようになります。データの並べ替え順序は通常、任意ではありません。並べ替えがない場合でも、省略によるビジネス上の決定であるためです（空のリストは引き続きリストです）。

しかし...これらの答えはORMテクノロジーの進歩を考慮に入れていないようです、私はエンティティフレームワーク（これが本当のORMであるかどうかについての議論を避けましょう、それはポイントではありません）に関連してのみ話すことができますそれが私が使用しているものですが、他のORMも同様の機能を提供していると確信しています。

MSMVCとEntityFrameworkを使用してProductクラスの厳密に型指定されたビューを作成し、ProductテーブルとImageテーブルの間に外部キー関係（FK_Product_Image_ProductIdなど）がある場合、すぐに並べ替えることができます。ビューで次のようなものを使用して表示中の画像：

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

特定のビジネスロジックレイヤーについて言及されました。これは、ビジネスロジックの80％を実行するためにも使用されますが、すぐに使用できるものを模倣するソート機能をビジネスロジックレイヤーに書き込むことはしません。エンティティフレームワークから。

それを言う以外に、この質問に対する正しい答えはないと思います。可能な場合は複雑なビジネスロジックを抽象化する必要がありますが、車輪の再発明を犠牲にすることはありません。

score 1 · Accepted Answer

MVC Webサイト、WebForms Webサイト、およびモバイルアプリケーションがあると想定します。

これらのプレゼンテーション層の間で並べ替えを一貫させたい場合は、プレゼンテーション層の外側で並べ替えると言います。サービスは良い候補になるでしょう。

それ以外の場合は、そのロジックをビューモデルに格納します。なんで？再利用可能で簡単にテストできるからです。

score 0 · Accepted Answer

あなたがリストした3つのうち、私はそれがコントローラーに属していると言うでしょう。ただし、この種のロジックをコントローラーに配置するのはあまり好きではありません。私は通常、コントローラーが通信するサービスレイヤーを作成します。このサービスレイヤーは、データストアとの通信と並べ替えロジックの処理を担当します。ただし、小規模なアプリケーションの場合は、コントローラーに座っても問題ありません。

score 0 · Accepted Answer

これはasp.netを念頭に置いて尋ねられた質問ですが、誰かがRailsについて言及したので、その文脈で問題を検討するのは興味深いと思いました。Railsでは、フレームワークとActiveRecord / ActiveQuery apiがプロビジョニングするため、コントローラーアクションとしての取得とともに並べ替えを実行するのは自然でかなり一般的です。一方、静的アイテムに対してある種のカスタムソート順を定義し、それをコントローラーが使用するモデルに入れることができるため、モデルは実行されなくてもソートロジックの役割を果たすことができます。直接操作。それが何であれ、ソートロジックをビューに配置することは一般的に眉をひそめていると言っても過言ではありません。

いくつかの答えは、コントローラーまたはモデルのいずれかにソートを入れることに絶対に反対であり、私の好みにはあまりにも衒学的であると私は少し面白がっていますが、それは使用されるフレームワークの性質と関連する通常の規則に依存すると思いますそれ。そもそも分離することがより重要であるというビルKのコメントにも同意します。