奇异,无所不包的UnitOfWork与多个较小的UnitOfWork抽象?

时间:2014-09-19 15:11:39

标签: design-patterns tdd repository-pattern unit-of-work solid-principles

我正在为Web应用程序构建数据访问层,并试图弄清楚是否应该使用单一的工作单元(UoW)来跟踪我的所有数据库活动(无论我是使用全部还是少数其中包含IRepository<T>,或根据特定工作流程UserUnitOfWorkSchedulesUnitOfWork等创建较小的工作单元。

我想知道一个大的UoW是否会违反单一责任原则,因为我的数据库不太可能改变,而不是传统的POCO对象(我用C#编码,但这可能不是那么相关)。如果我有一个需要对数据库进行多次更改的流程,那么创建一个大型UoW可能会更好,因为对于每个UoW实例我都不需要.Commit(),只需要一次。

如果我将较小的UoW基于特定的“流”,那么通常情况下我会有重叠的具体存储库类(例如,SqlRepository<User>可以非常频繁地使用)。这个代码重复显然是DRY违规,但这意味着我的小UoW更容易阅读,导航和更改。

这仅仅归结为设计决策吗?较小/较大的UoW之间是否有任何权衡?选择其中一个时会对可测试性产生什么影响?对此有任何建议将不胜感激。

1 个答案:

答案 0 :(得分:0)

真正的建筑师答案是“它取决于”。

在代码变成抽象思考的情况下,我将为您提供关于这些事情的我自己的思维方式。这肯定是一个非典型的答案。让我们看看我得到了多少票。

尝试将此视为人,群体,并假装您正在尝试学习新事物。它变成了一个协调问题。

如果您是唯一一个学习的人,并且您的时间比所有其他人/团体更重要,那么您提出问题的最有效方式就是让所有人都和您在同一个房间,这样您就可以问问题并立即得到答复。

在他看来,你是唯一一个学习的人,但是你的时间不那么或者同样值得其他人的时间,你将被迫将答疑组分成小组,并构建你的学习过程。在他的情况下,您将有机会针对特定群体提出有关特定情景的问题。

现在将此应用于多个学习相同内容的人。在这种情况下,您可以收集在清酒室中的所有学习人员,同时学习在房间里回答的所有资源。这是一个典型的会议室面板Q&amp; A会议。

将它应用于多个学习相同内容的人,构建学习,并让人们同时回答房间中的特定部分。典型的教室设置。

然后是最后的变种,你有学习站。人们学习可以在不同的站点走动,向每个站点提问。每个电台都由人们根据不同场景回答问题。

然后将其转换为交易和工作单元。人们将问题视为请求,人们将其作为资源回答(如DB)。组织这个的人当然是交易协调员。

我认为你会发现它变成了成本效益计算。锁定资源的成本,以及在需要时拥有资源的好处。因此,唯一真正的答案是“它取决于”。

意见:一般来说,我会说最有效的学习方式而不浪费资源就是将学习过程分解为单独的活动,根据场景设置应答站,并确保回答问题的人在等待某人提问时可以自由地做其他工作。最后,您可能希望订购车站的顺序,以确保所有人不会在清醒时前往同一车站。如果他们这样做,也许可以从上面考虑其他学习过程。

对我而言,这意味着将UoW保持为尽可能小和孤立。如果(对于所讨论的系统)做教室风格是有意义的,请考虑批处理。如果成本/性能不是问题,请执行大型UoW,因为它可能使维护更容易。最后,如果成本确实不是问题,但你需要认真对待整个面板风格,批量和做大UoW。