此应用程序的用户需要跟踪员工的多种时间类型.为了简单起见,我们只考虑两个.我会称他们为“时间卡”和“出席”.这两者之间的差异的确切性质并不重要,但您应该注意到最终用户将它们完全分开.我认为,他们认为他们完全分开数据的原因是,他们从来没有真正有机会在过去看到他们.这两种类型的记录在编辑记录方面几乎完全不同,但一般而言,他们也是在特定时间的员工的记录.两种类型的时间记录具有很多属性,例如总时数,以及收集时间的员工.这两种类型也具有一些完全独特的属性.我们将这些“额外”属性保留在另一种类型的实例中.所以一般结构如下所示：

class TimeRecord 
{ 
    Person Employee { get; set; }
    TimeSpan? Hours { get; set; }
}

class TimeCardData
{
     TimeRecord Record { get; set; }
     TProperty TimeCardProperty  { get; set; }
}

class AttendanceData
{
     TimeRecord Record { get; set; }
     TProperty AttendanceProperty  { get; set; }
}

所以问题是,这里需要多少个仓库？

1存储库

只有一个存储库的设计将公开方法在一个列表中返回“时间卡”,“考勤”记录或两种类型.这对于仓库的客户来说是相当方便的,但在我看来,这是真正的危险,成为一个非常胖的班级.我认为只有“时间卡”的存储库已经是系统中最大的存储库之一,即使没有处理“考勤”,只是因为涉及复杂的业务规则.

2存储库

另一个设计将有一个“时间卡”存储库和另一个“考勤”记录库.这具有的优点是,例如“时间卡”的业务规则自己在一个地方.但是,我也想有一种方法来获取所有时间记录的列表,不管类型如何.目前还不清楚哪种存储库用于这种情况.都？

3存储库

具有“时间卡”一个存储库的设计,另一个“考勤”记录存储库,以及提供所有时间记录的只读列表的第三个存储库也是可能的.像2存储库设计一样,这样做的优点在于,例如“时间卡”的业务规则本身就在一个地方.现在清楚在哪里获得组合列表.但是我觉得有点奇怪,我可以从两个不同的存储库获得相同的记录.

混合动力

混合方法将使用单个存储库,但将任何业务规则代码(包括选择记录)移动到单独的类型中.在此示例中,单个“时间记录存储库”会聚合“时间卡”和“考勤”时间的业务规则实现类的实例.我认为这是我现在喜欢的方法.

其他？

我错过了什么？一个设计的另一个引人注目的论据？