子类化视图模型并添加额外的属性

本文关键字:属性 添加 视图 模型 子类 | 更新日期: 2023-09-27 18:03:45

好的,我有一个像这样的界面

public interface PersonRepository {
    PersonViewModel GetByName(string name);
}

PersonViewModel非常简单,看起来像这样

public class PersonViewModel {
    public string FullName { get; set; }
}

这个应用程序的上下文是我们正在托管一个ASP。NET MVC站点,充当网站(JS/HTML)和一些Obj-C和Java客户端的端点。它将数据公开为JSON。

我们想要实现的是我们的分布式团队知道他们可以期望从服务中得到的最小值是什么。但我们也希望能够灵活地添加内容,而不会破坏彼此。

因此,视图模型和接口由提供所需的公共对象的核心团队拥有。它们将这些公共对象作为DLL分发,因此不提供源代码。

现在我的问题是,web团队想要引入Age,因为他们真的需要在只存在于HTML/JS客户端的帐户页面上。

这样子类化PersonViewModel是一个好办法吗

public class PersonWithAgeViewModel : PersonViewModel {
    public int Age { get; set; }
}

在存储库的实现中,它需要看起来像这样,然后

 public class PersonWithAgeFromDBRepository : PersonRepository
{
    public PersonViewModel GetByName(string name)
    {
        //.. Get data from DB
        var person = new PersonWithAgeViewModel(){ Age = 13, FullName = "Hello World"};
        return (PersonViewModel)person; // Cast to person view model
    }
}

当然,我需要设置网站使用我们的新存储库。

我不确定的是,我得到的感觉是,我滥用接口和PersonViewModel类型只是作为另一种类型的传输机制。它将工作,因为我将在JSON中正确序列化数据,并且我的客户端可以使用它。但这是解决问题的好办法吗?

我将错过的是没有什么可以保证客户端这个Age属性存在。引进新属性的人也将是消费新属性的人。

子类化视图模型并添加额外的属性

如果你使用personrepository接口,你将永远无法保证你得到一个PersonWithAgeViewModel。这就是有这个界面的意义。你的保证就是一个PersonViewModel。

您可以考虑的另一种选择是组合http://en.wikipedia.org/wiki/Composition_over_inheritance

你仍然不能保证age的存在,但这是让不同的团队使用相同的界面添加自己的功能的另一种方式。