c# - ASP.NETMVCの設計上の問題

Question

ModelとViewModelの違いは何ですか？両方を使用する必要がありますか、それとも一方をスキップする方がよいですか？データベースからデータを取得するのは誰ですか？
データベースからデータを取得するための最良の/正しい方法は何でしょうか。

1つのオプションは、DAL（データアクセス層）を用意し、それをすべてのコントローラーでインスタンス化し、次のようなビューモデルを入力することです。

var viewmodel = Dal.GetArticles();

もう1つのオプションは、モデル自体がデータベースから情報を取得できるようにすることです。

var model = new ArticlesModel();
model.GetArticles();

public void GetArticles()
{
var context = new DbContext();
_articles = context.Articles
}

別の同様のオプションは、静的DALを使用してすべてのモデル内でアクセスできるようにすることです。これにより、各モデルには、静的DALクラス（データベースにアクセスするためのDbContextクラスが内部に含まれる）を使用してデータを取得するメソッドがあります。

public void GetArticles()
{
_articles = DAL.GetArticles();
}

したがって、一般的な質問は、モデル自体がデータベースからデータを取得する必要があるのか、それともコントローラー自体がDALにアクセスできるのかということです。

score 4 · Accepted Answer

誰かがもっと役立つ答えを書いている間、私はあなたのポイントにすぐに対処します。

Model表示したいデータです。

多くの場合、オブジェクトリレーショナルマッピングを使用して、ほとんどのビジネスオブジェクトクラスがデータベーステーブルに対応し、手動でクエリを作成する必要がないようにします。

Entity Framework、NHibernate、（現在は死にかけている）LINQ to SQLなど、利用可能なORMソリューションはたくさんあります。

Dapperと呼ばれる素晴らしいマイクロORMもあります。これは、より大きなフレームワークがソリューションに対して不必要に肥大化していると感じた場合に役立ちます。

それらの違いについて必ず学んでください。

DALは、自分自身をロードする方法を「知っている」クラスよりも.NETで慣用的です。

（実際には、ソリューションは両方のアプローチを組み合わせたものになる可能性が非常に高くなります。重要なのは、いつものように、バランスを保つことです。）

私のアドバイスは、ORMで許可されている限り、また呼び出し元のコードに余分なレベルの複雑さが加わらない限り、モデルを古いCLRオブジェクトのままにしておくことです。

これらのオブジェクトは、可能な限り（そして賢明な場合、どのルールにも例外があります！）、特定のデータベースまたはORM実装に関連付けるべきではありません。

必要に応じて、コードを別のORMに移行するだけで、データアクセス層を書き換えることができます。
ただし、これがDALを分離する主な理由ではないことを理解する必要があります。

プロジェクトの途中でORMを変更する可能性はほとんどありません。ただし、最初の選択が目的に適さない場合や、突然10万人のユーザーを獲得し、ORMで処理できない場合を除きます。最初にこれを最適化することは、最適化するヒットのほんの一部でも引き付けることができる優れた製品を作成することからあなたをそらすので、まったく愚かです。（免責事項：私は以前にこの道を歩いたことがあります。）

むしろ、DALの利点は、データベースアクセスが常に明示的になり、それを実行したい特定の場所に制限されることです。たとえば、表示するモデルオブジェクトを受け取ったビューは、データベースから何かをロードしようとはしません。これは、実際には、コントローラーの仕事だからです。

また、一般的に、ビジネスロジック、プレゼンテーションロジック、データベースロジックなどを分離することもできます。あまりにも多くの場合、それはより良い、バグの少ないコードになります。また、データベースからロードされているオブジェクトに依存するコードを単体テストするのは難しい場合があります。一方、「偽の」メモリ内データアクセス層を作成することは、LINQでは簡単です。

ビュー内で呼び出された場合でも、外出先で関連オブジェクトをロードする多くのORMによって生成されるレイジープロパティなど、このルールには例外があることに注意してください。したがって、重要なのは、データアクセスを許可する時期とその理由を十分な情報に基づいて決定する必要があるということです。シンタックスシュガーは役立つかもしれませんが、チームがORMから20,000個のオブジェクトをロードすることのパフォーマンスへの影響について知らない場合、それは問題になります。

ORMを使用する前に、内部でどのように機能するかを学びます。

Active RecordスタイルのオブジェクトとDALのどちらを選択するかは、ほとんどの場合、好み、.NETの一般的なイディオム、チームの習慣、およびDALを最終的に置き換える必要がある可能性の問題です。

最後に、ViewModelsは別の種類の獣です。

次のように考えてみてください。

ビューには、よりも洗練されたロジックを含めるべきではありませんif-then-else。
ただし、多くの場合、物事を表示する際にいくつかの洗練されたロジックがあります。ページネーション、並べ替え、1つのビューでのさまざまなモデルの組み合わせ、UIの状態の理解について考えてください。

これらは、ビューモデルが処理できる種類のものです。
単純なケースでは、いくつかの異なるモデルを1つの「ビューモデル」に結合するだけです。

class AddOrderViewModel {
    // So the user knows what is already ordered
    public IEnumerable<Order> PreviousOrders { get; set; }
    // Object being added (keeping a reference in case of validation errors)
    public Order CurrentOrder { get; set; }
}

モデルは単なるデータであり、コントローラーはデータを組み合わせて、ビューモデルに表示されるデータを記述するためのロジックを導入し、ビューはビューモデルをレンダリングするだけです。

ビューモデルは一種のドキュメントとしても機能します。彼らは2つの質問に答えます：

ビューで使用できるデータは何ですか？
コントローラでどのようなデータを準備する必要がありますか？

オブジェクトを渡しViewData、名前と型を記憶する代わりに、ジェネリックビューを使用ViewModelして、静的に型付けされ、IntelliSenseで使用できるプロパティにオブジェクトを配置します。

また、階層を作成すると便利な場合がViewModelあります（ただし、極端にしないでください）。たとえば、サイト全体のナビゲーションがブレッドクラムから別のものに変更された場合、ベースビューモデルのプロパティ、それを表示するための部分ビュー、およびベースコントローラでそれを構築するためのロジックを置き換えるだけでかまいません。それを賢明に保ちなさい。

score 2 · Accepted Answer

モデルは、データが好きな構造を表し、データを消費する可能性のあるビューを気にしません。モデルの意図は、純粋に構造を表現することです。

モデルには、それを使用するビューに関係のないプロパティが含まれている場合があります。

ビューモデルは、ビューを念頭に置いて設計されています。ビューモデルは、ビューとの1対1の関係を対象としています。ビューモデルには、目的のビューに必要な基本的なフィールドとプロパティのみが含まれています。

一般に、コントローラーにリポジトリー（この例ではDAL）に接続してデータを取得し、モデルまたはビューモデルに結果を入力して、ビューに送信します。

score 1 · Accepted Answer

モデル（ドメインモデル）：アプリケーションの中心であり、すべての複雑なビジネスエンティティ、それらの関係、およびそれらの機能をキャプチャするため、最大かつ最も重要なビジネス資産を表します。

ViewModel：モデルの上に座っているのはViewModelです：ViewModelの2つの主要な目標は、1。モデルをビューで簡単に使用できるようにすることと、2。モデルをビューから分離してカプセル化することです。

例えば。

モデル：

public class Product
{
...............
}

public class Category
{
...........
}

ViewModel：

public class ProductViewModel
    {
        public ProductViewModel(List<Product> products, List<Category> categories)
        {
            this.Products = products;
            this.Categories = categories;
        }

        public List<Product> Products { get; set; }
        public List<Category> Categories { get; set; }

    }

c# - ASP.NETMVCの設計上の問題

3 に答える 3

Related

Reference