MVVM 中 Model 和 ViewModel 的说明和命名约定

Question

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

为简单起见，我将不使用 INotifyPropertyChange。

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

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

您在网上看到的最多的是视图模型的定义如下：

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

    public ObservableCollection<CountryModel> Countries
    {
        private 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;
    }
}

上面说的有道理吗？我只是不明白为什么它似乎是一个标准，为什么你会打电话给 CountriesViewModel 什么时候对我来说应该是 CountriesModel 并且应该创建一个 CountryViewModel 来访问来自 CountriesModel 的数据。

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

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

如何正确定义？尤其是您拥有对象列表并且每个对象都包含另一个列表的部分。哪个是模型，哪个是视图模型，如何处理模型中的列表？

Answer 1

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

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

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

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

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