MVVMのモデルとViewModelの明確化と命名規則

Question

モデルやビューモデルとなるべきものと、これらの名前の付け方を混同しています。

わかりやすくするために、INotifyPropertyChangeを残しておきます。

次のクラスは明らかにモデルです：

class CountryViewModel 
{ 
    public CountryViewModel 
    { 
     // initialize data (not ideal place, I know, but keeping it simple!) 
    } 

    public ObservableCollection<CountryModel> Countries 
    { 
     private get; 
     set; 
    } 
} 

なぜ上記ではありません：あなたは主にウェブ上で見る何

class CountryModel 
{ 
    public string Name { get; set; } 
    public string Location { get; set; } 
} 

は、次のようにビューモデルが定義されるだろうということですCountriesのモデル、すなわちCountriesModel、例えば？なぜそれはビューモデルと見なされますか？

それは技術的にそうであるべきですか？ビューモデルの別のクラスを用意する必要がありますか？

class CountryViewModel 
{ 
    private ObservableCollection<CountryModel> _countries = new ....; 

    public CountryViewModel 
    { 

    } 

    public ObservableCollection<CountryModel> Countries 
    { 
     private get { return _countries ?? _countries = LoadCountries(); } 
     set { _countries = value; } 
    } 

    private ObservableCollection<CountryModel> LoadCountries() 
    { 
     ObservableCollection<CountryModel> countries = new ...; 
     foreach (CountryModel country in CountriesModel) 
     { 
      countries.add(country); 
     } 
     return countries; 
    } 
} 

上記の意味はありますか？私はちょうどそれが標準と思われる理由を理解していないと私はそれがCountriesModelとCountryViewModelCountriesModelからのデータにアクセスするように作成する必要がありますCountriesViewModelを呼び出す理由を理解していない。

CountryModelとCountryViewModelに観測可能なコレクションCountryModelが含まれている場合は、各都市のリストを含む国はどのように扱いますか？私はCityModelをPOCOとして持っていて、次に都市リストのために、CityModelの観測可能なコレクションを持つCityViewModelを作成します。

しかし、それでは？ CityViewModelを私のCountryModelの一部にしなければなりませんか？それはまったく正しいとは思わない！多分それはあり、誰かがそれを明らかにすることができます。これは、プロパティName、Location、タイプがList<CityModel>のCountryModelを作成したので、さらに混乱するところですが、これをMVVMで正しく表現するにはどうすればよいですか？

これを正しく定義するにはどうすればよいですか？特に、オブジェクトのリストとそれらのオブジェクトのそれぞれの部分が別のリストを含んでいます。どのモデル、ビューモデル、どのように私のモデル内のリストを処理するのですか？

Answer 1

一般的に、ユーザーはシステム内にあるすべてのビューのビューモデルを作成します。ビューモデルの目的は、ビューのデータを容易にすることです。ビューモデルは、通常、ドメインモデルの対応版のフラット化されたバージョンですが、実際にはデータ転送オブジェクト（DTO）だけであるフラットなドメインモデルを使用すると混乱するように見えます。ドメインモデルによく似たビューモデルを持つのを恐れ​​ないでください。それらは、アプリケーションのさまざまな領域/レイヤーで生きて働くことを意図したデータの異なる抽象です。

あなたの質問/例としては、国や都市を階層的な性質で表現したアプリケーションのビューがある場合は、CountryViewModelがCityViewModelと他のもの特定のビューのデータを構成するのに役立つモデルを表示できます。また、ビューモデルで継承を使用して、データの取得、データのマッピング、データの検証などの問題のエラー情報を保持するベースビューモデルクラスを作成することもできます。

あなたは、一般的に、アプリケーションのビューあたりのビューモデルを持っていることになるでしょうので、あなたの多くの時間があなたのドメインモデルオブジェクトのCRUD操作に一致するビューモデルのセットで終わります。たとえば、あなたがAccountドメインモデルを持っていると言う、あなたはおそらくCreateAccountViewModel、DisplayAccountViewModel、DeleteAccountViewModelとUpdateAccountViewModelを持っているでしょう。

多くの人が自分のコード内の重複に関心を取得し、構造とデータ型ではほとんど同じで、ドメインモデルとビューモデルを持っているが、彼らは非常に異なる目的を果たすことを覚えておくことは間違っていると思います。ビュー内にユーザーに情報を表示するためのデータを容易にするためのビュー・モデルが存在しますが、作業中の問題空間のデータを容易にするためにドメイン・モデルが存在します。

ドメインモデルとは異なるが、データベース・テーブルから取得されるデータの構造を反映したデータ・アクセス・レイヤーのデータモデルクラスを有することも前代未聞ではありません。これはDapperのようなマイクロORMを使用する方法です。 ADO.NET DataReaderマッピングロジックを記述する代わりに、データベースからデータを取得し、そのクラスをオブジェクトとして使用してデータを「ダンプ」するために使用するクエリの列名と一致するデータモデルクラスを作成します。そこから、アプリケーションのレイヤーに戻って渡されるドメインモデルクラスを構築するためのマッピングロジックを持つことができます。