我正在为 MVC 应用程序构建一些存储库,并且我正在尝试提出在存储库之间划分职责的正确方法。在大多数情况下,这是显而易见的。但是有一种特殊情况,我不确定正确的答案是什么。
此应用程序的用户需要为其员工跟踪多种类型的时间。为简单起见,我们只考虑两个。我称它们为“考勤卡”和“考勤”。这两者之间差异的确切性质并不重要,但您应该注意最终用户将它们视为完全独立的数据。不过,我认为,他们认为它们完全独立的数据的原因是他们过去从未真正有机会看到它们在一起。这两种类型的记录在编辑记录方面具有几乎完全不同的业务规则,但一般来说,它们也是员工在特定时间所处位置的两种记录。这两种时间记录有很多共同的属性,比如总小时数,以及为其收集时间的员工。这两种类型还具有一些完全独特的单个类型的属性。我们将这些“额外”属性保存在另一种类型的实例中。所以一般的结构是这样的:
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 存储库设计一样,这具有优势,例如,“时间卡”的业务规则位于一个位置。现在很清楚从何处获取组合列表。但是我发现我可以从两个不同的存储库中获得相同的记录有点奇怪。
杂交种
混合方法将使用单个存储库,但将任何业务规则代码(包括记录选择)移动到单独的类型中。在此示例中,单个“时间记录存储库”将聚合“时间卡”和“出勤”时间的业务规则实现类的实例。我认为这是我现在喜欢的方法。
其他?
我错过了什么?一种设计优于另一种设计有什么令人信服的论据吗?