c# - MVVM 中 Model 和 ViewModel 的澄清和命名约定

Question

我对什么应该是模型或 View 模型以及它们应该如何命名感到困惑。

为简单起见，我将保留 INotifyPropertyChange

下面的类显然是一个模型:

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

您在网络上最常看到的是 View 模型定义如下:

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

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

为什么上面的不是Countries的模型，即 CountriesModel ， 例如？为什么它被认为是 View 模型？

技术上应该是这样吗？那么我们是否应该为 View 模型创建另一个类？

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

上面说的有道理吗？我只是不明白为什么它似乎是一个标准以及为什么你会调用 CountriesViewModel什么时候对我来说应该是CountriesModel和一个 CountryViewModel应该创建访问来自 CountriesModel 的数据.

此外，如果您坚持使用网络上的内容，即 CountryModel和 CountryViewModel包含 CountryModel 的可观察集合，那么你将如何处理包含每个城市列表的国家？我会有一个 CityModel作为 POCO 然后对于城市列表，我将创建一个 CityViewModel拥有 CityModel 的可观察集合.

然后呢？我应该制作 CityViewModel 吗？我的一部分 CountryModel ？这似乎根本不对!也许是这样，有人可以澄清这一点。这是我更加困惑的地方，因为我会创建一个 CountryModel具有属性 Name , Location和 List<CityModel> 类型的属性，但我如何在 MVVM 中正确表示它？

如何正确定义这个？特别是你有一个对象列表并且每个对象都包含另一个列表的部分。哪个是模型、 View 模型以及如何处理模型中的列表？

Answer 1

通常，人们会为系统中的每个 View 创建一个 View 模型。 View 模型的目的是方便 View 的数据。 View 模型通常是其域模型副本的扁平化版本，但是当您拥有实际上只是数据传输对象 (DTO) 的扁平域模型时，这看起来会令人困惑。不要害怕拥有与领域模型非常相似的 View 模型；它们是旨在在应用程序的不同区域/层中生活和工作的数据的不同抽象。

至于您的问题/示例，如果您的应用程序中有一个以层次结构表示国家和城市的 View ，那么是的，完全可以接受由以下内容组成的 CountryViewModel CityViewModel，以及帮助构成该特定 View 数据的任何其他 View 模型。也可以在 View 模型中使用继承，这样您就可以拥有基础 View 模型类，其中包含任何出错的错误信息，例如检索数据的问题、映射数据的问题或验证数据的问题。

由于您通常希望应用程序中的每个 View 都有一个 View 模型，因此您最终会得到一组与域模型对象的 CRUD 操作相匹配的 View 模型。例如，假设您有一个 Account 域模型，那么您可能会有一个 CreateAccountViewModel、DisplayAccountViewModel、DeleteAccountViewModel和 UpdateAccountViewModel。

许多人担心代码中的重复，并认为拥有在结构和数据类型上几乎相同的域模型和 View 模型是错误的，但请记住它们的用途截然不同；领域模型的存在是为了促进您正在处理的问题空间的数据，而 View 模型的存在是为了促进在 View 中向用户显示信息的数据。

在数据访问层中有一个不同于领域模型的数据模型类也不是闻所未闻，但它反射(reflect)了从数据库表中检索的数据的结构。这就是您如何使用像 Dapper 这样的微型 ORM。您无需编写 ADO.NET DataReader 映射逻辑，而是创建一个数据模型类，该类匹配您用于从数据库中检索数据的查询中的列名，然后将该类用作对象将数据“转储”到。从那里你可以有映射逻辑来构建一个域模型类，该类被传递回你的应用程序的层。