1

我目前正在构建一个 ASP.net MVC 应用程序，该应用程序已分解为多个模块（以及一个通用类库）。

我已经为我的第一个模块实现了一个工作单元模式。这个工作单元类包含许多不同的存储库。

但是，我想知道为每个模块设置一个单独的工作单元类是否是个好主意？

4

3 回答 3

0

请看这个和这个 工作单元实际上只是一种跟踪已加载到内存中的一组实体的方式。加载后，我们可以以正常方式处理实体：更改状态、添加新实体和删除其他实体。当我们准备好保存更改时，我们要求工作单元提交，它负责将未决更改“刷新”到底层数据库。

于 2013-01-30T16:31:16.077 回答
0

为每个模块设置一个单独的工作单元类是个好主意吗？

我的第一个想法是：一个模块的工作单元与另一个模块的工作单元有何不同？如果他们这样做了，他们可能不应该这样做，因为域应该不知道持久性，而数据层应该不知道业务逻辑。

以实体框架本身附带的 UoW 为例：上下文。[当您创建上下文、执行操作、调用SaveChanges()和处理它时，它就像 UoW 一样]。您可以为整个应用程序使用一个上下文类。您不会在上下文类中编写任何业务逻辑。因此，除非每个模块都使用数据库中真正不同的部分（这几乎不是真的），否则没有理由为每个模块设置一个上下文类。您自己创建的 UoW 也是如此。

这有点超出了您的问题范围，但是您可以问自己是否需要自己的 UoW 和存储库类，因为 EF 提供了两者的基本实现（上下文和DbSets）。

于 2013-01-30T18:34:19.433 回答
0

好吧，EF 为您提供了自己实现的 UnitOfWork 和 Repository 模式。通常它们并不完全是您想要的，向原生 EF 存储库添加一些方法似乎很好，但在大多数情况下，这不值得麻烦。

如果您的项目很简单，那么基于 EF 实现您自己的存储库并不是一个好主意。它增加了很多工作，但没有那么多价值。

基于 EF 实现 UnitOfWork 是完全不同的故事。我能看到这样做的唯一原因是“对解决方案的不同部分有不同的 UoW”。避免它，否则，真的。

我们尝试添加这两种方法，而忽略我们项目中的预建方法。这是完全合理的，因为我们正在设计模块化解决方案，我们甚至不知道最终会有多少个模块。我们希望在系统已经运行且负载很重时向系统添加新模块。我可以说开发这样的应用程序花了很多时间。当您意识到您需要从某个模块访问更多实体时，会导致几个地方发生变化——这是低效设计的第一个证据。

所以，KISS 和 YAGNI 反对它。如果您被“我应该将这些东西添加到我的项目中”的问题所困扰 - 只是不要。你需要一个充分的理由来自己实现这些部分，而不仅仅是一些“好的设计”偏见，因为它增加了很多复杂性。即使你认为有一天你会需要它——等到那一天。如果您尝试估计哪种错误计算会造成更大的灾难性后果，我很确定在您的项目中添加新内容然后删除已经存在的内容要容易得多。

于 2013-01-31T08:13:06.853 回答