问题标签 [unit-of-work]

我看到几个与此相关的问题，但我仍然找不到我正在寻找的答案，所以我发布了我的问题。如果另一个问题有答案（而我只是没有看到），请指出它。

当将 EF4 和 Unity 与 Repository 模式一起使用时，我试图找出我的 UnitOfWork 所属的位置——特别是被创建的位置。

基本上，我有一个用于实现我的业务逻辑的服务。此服务构造函数接收存储库，因此服务被注入我的存储库。然后该服务使用注入的存储库对数据存储执行操作——但我需要将它们包装在一个工作单元中。

但是，我的工作单元需要注入 EF4 上下文（或者，在我的情况下，以及上下文的接口——IObjectContext）。而且我不确定应该在哪里创建和注入 UoW。

以下是我能想到的可能选项，但似乎都不理想：

• 在服务构造函数中包含 UoW，从而使服务与工作单元一起注入，而工作单元又与我的 EF4 上下文一起注入。但这似乎是错误的，因为我不希望在存储库的每个实例上创建我的 UoW。

• 使用 container.Resolve 进行按需创建以获取 UoW 的实例，注入我的 EF4 上下文。不得不不断地访问 IoC 容器，而不是已经可以访问 UoW，这似乎有点过分了。

• 将上下文直接注入到服务中，允许我创建一个 UoW（上下文）。这似乎很糟糕，因为我现在已经向服务公开了上下文，这应该与存储库隔离。

所以我的问题是，这些方法中的一种是可以接受的，还是我没有想到的另一种方法？

提前致谢。

我正在开发一个现有系统（asp.net 2，ms sql server 2005），其中存储库模式的实现如下：

该系统有3种不同的产品。所以我们对每个产品都有不同的存储库。随着需求随着时间的推移而变化，我们需要为业务流程级别的事务实现工作单元模式。
我们没有任何 ORM。（实际上我们现在没有权限或时间来实现它）谁能给我一个明确的指导方针，如何仅使用 TransactionScope 和 sqlconnections 来实现工作单元。

请提一下如何快速有效地关闭 Sqlconnections（因为它有大量用户）。
工作单元模式对我来说是新事物。
提前致谢 ...

我正在尝试了解工作单元模式。但是，我很难找到一个不太简单或不太复杂的示例。所以决定试着从我读过的东西中写一些我自己的东西。我想知道我所做的是否可以接受。我正在尝试将图层解耦。我创建 DatabaseManager 的原因是为了避免将上下文发送到其他层。最后，这将是具有中间层（业务）的 MVC 应用程序的 DAL

感谢您的输入。

代码：

编辑：新代码

我只是在寻找一些关于其他人在使用 EF4 时如何管理他们的上下文的反馈。我正在创建一个 MVC 应用程序，使用（我认为 :)）工作单元、服务层、存储库、EF4 w/POCO 技术。

我的控制器利用采用 UOW 的服务，然后利用存储库从 EF 获取 POCO。

这是否正确实施？

看看下面，任何反馈表示赞赏！

控制器

工作单元

服务

存储库

我有一个使用 UnitOfWork、服务层、存储库模式和 EF4 作为 ORM 的 MVC 应用程序。

我的问题是这个（UnitOfWork）是否具有一个属性，即 EF 的上下文紧密耦合我的层？

工作单元

服务

存储库

我正在使用带有 EF4 的服务层/存储库/工作单元模式构建一个 MVC 应用程序。

我对逻辑有点困惑。我知道重点是解耦系统，但我有点困惑。

所以 MVC 控制器调用服务来填充视图模型。那么说 MVC 应用程序与服务层耦合是否安全？

然后服务层调用存储库来获取和持久化对象。那么可以安全地说服务层依赖于存储库吗？

存储库利用 EF4 获取数据并将数据保存到 SQL Server，因此我假设存储库依赖于 EF4，而 EF4 又依赖于 SQL Server。

工作单元在哪里都适合。

请问有什么例子吗？谢谢！！

我在我的 MVC 应用程序中使用 UnitOfWork/Service Layer/Repository/EF4 w/POCO 设计。

到目前为止，我有这个：

1) MVC Web App (Project.dll)
2) 服务层 (Project.Data.Services.dll)
3) 存储层 (Project.Data.Repositories.dll)
4) POCOS (Project.Data.Domain.dll)
5) EF4/上下文层 (Project.Data.dll)

每个图层仅引用下面的图层和 Project.Data.Domain（POCO 类）。

我目前在 Project.Data.dll 中有 UnitOfWork 接口/基础，但现在所有层都必须引用它。这是一个糟糕的设计吗？如果是这样，它住在哪里？

我仍然很难解决这个问题。我想像这样分离我的层（dll）：

1) MyProject.Web.dll - MVC Web 应用程序（控制器、模型（编辑/视图）、视图）
2) MyProject.Services.dll - 服务层（业务逻辑）
3) MyProject.Repositories.dll - 存储库
4) MyProject。 Domain.dll - POCO 类
5) MyProject.Data.dll - EF4

工作流程：

1) 控制器调用服务来获取对象以填充视图/编辑模型。
2) 服务调用存储库来获取/持久化对象。
3) 存储库调用 EF 以从 SQL Server 获取/保留对象。

我的存储库返回 IQueryable(Of T)，并在其中使用 ObjectSet(Of T)。

所以正如我所看到的，这些层完全取决于下一层和包含 POCO 类的库？

几个问题：

1) 现在我的存储库可以与 EF 一起正常工作，它们将依赖于 System.Data.Objects，现在我的存储库层与 EF 紧密耦合，这很糟糕吗？

2）我正在使用 UnitOfWork 模式。那应该住在哪里？它有一个作为 ObjectContext 的属性上下文，因此它也与 EF 紧密耦合。坏的？

3) 我如何使用 DI 使这更容易？

我希望这是一个尽可能松耦合的测试。有什么建议么？

- - - - - 编辑 - - - - -

如果我在正确的轨道上，请告诉我。此外，因此服务被注入了一个 IRepository(Of Category) 对，它如何知道它与 EFRepository(Of T) 的具体类之间的区别？与 UnitOfWork 和服务相同吗？

一旦有人帮我弄清楚我理解的地方，我知道这似乎是微不足道的，但是伙计，我有一段时间在这个问题上纠结！！

控制器

服务

存储库和工作单元

我真的很难弄清楚 EF 上下文在 MVC 应用程序中的管理位置。

我正在使用 Service/Repository/EF 方法，并且正在使用 UnitOfWork 模式及其内部的上下文，然后在控制器操作中使用它来利用各种服务。它有效，但是通过这样做，我使控制器依赖于 EF 对吗？

有什么建议么？

我正在使用带有 POCO 类的统一实体框架 4、用于 DAL 的存储库模式和用于业务逻辑控制的服务。我还想使用工作单元，这样我就可以将我在不同服务上执行的 CRUD 操作打包在一起，然后将它们一起提交。

我的问题是使用 Microsoft Unity 将工作单元机制注入我的应用程序的正确方法是什么？我知道我可以将 IUnitOfWork 与适当服务的构造函数上的存储库放在一起，然后如果指定 Unity 映射，它将自动启动适当的实例，但这样我不会传递全局工作单元而是创建一个每个级别上的新实例，这不是一个聪明的方法（实际上存储库甚至在服务之前启动）。

我错过了什么？（附件是我现在编写的服务及其存储库的构造函数代码）。

你也明白我可以使用 Unity 的 ParameterOverrides 方法获取工作单元的一些全局实例（比如说从我的 aspx.cs 文件中）并将其传递到服务中，然后传递到存储库中。但这似乎有点蹩脚。这是我唯一的选择吗？

谢谢