1

例如，考虑：

public interface IStaff
{
    FullName name { get; set; }
    EMailAddress email_address { get; set; }
    SocialInsuranceId ssn { get; set; }
    PositiveInt age { get; set; }
    Address home_address { get; set; }
}

对于某些用户，视图模型只需要name和email_address。其他人可能有一个视图模型，其中包括这些属性加上ssn,age和home_address。假设还有一个统计学家，他的观点得到age和home_address。

现在，我可以将其拆分为IStaffBasic、IStaffDetails和IStaffStats接口继承，以将给定视图模型中的 API 限制为适当的属性。

但是，当通过网络从数据服务中检索到此实体时，它仍将包含其他详细信息，这些信息不得出现。

因此，最好
(A) 为这些版本中的每一个创建完全不同的实体类型，在某种程度上污染服务层 API，为每种类型使用许多额外的近乎重复的查询操作，或者
(B) 总是返回一个Staff实体，但是 ( 1）从服务中返回它们，并根据服务null的授权检查将排除的属性设置为；（2）如上所述在视图模型中使用有限的接口，或者
（C）使用我没有的非常优雅的模式或解决方案考虑过，但你要告诉我。

选项 A 在视图模型级别看起来更干净，但服务 API 会很讨厌。选项 B 似乎增加了服务器上实体处理的复杂性，但更好地遵守了开闭原则。

想法？

4

1 回答 1

1

投影是要走的路 - 结合选项 A 和 B。

您的 ORM 应该只与单个实体类型交互Staff，因此您只需要维护（和扩展）一组映射、查询等。

但是，您还将创建适用于每个安全场景（ 、 等）的不同类IStaffBasic，IStaffDetails将Staff实例投影到这些类中，并通过网络返回投影对象：

一些 ORM 支持将投影作为框架功能，但如果需要，您可以在服务层中手动进行。

于 2010-02-02T16:33:57.107 回答