一次打开多个 UnitOfWork 实例（ASP.Net 应用程序）是一个坏主意吗？
我正在开发一个应用程序，使用 Entity Framework 4.1 作为我的数据访问层。我创建了几个与不同实体一起使用的存储库。每个存储库作为构造函数的一部分，都接受一个 UnitOfWork 对象。然后，我使用服务层创建了这些存储库的抽象。每个层都会创建一个 UnitOfWork，然后将其传递到各自的存储库。
在我的服务层中，我是否应该只打开一个可供我创建的所有服务使用的 UOW？我还没有遇到任何问题，但想知道我所做的事情是否可能会导致问题。
请注意，在我的 Web 应用程序中，在插入更新数据时，我一次仅使用一种实体类型。当我必须为主实体实例化一项服务，然后可能实例化另一项服务来读取来自数据库中的配置表的静态数据时，我感到担忧。
I have an application I am working on, using Entity Framework 4.1 as my data access layer. I have created several repositories that work with different entities. Each repository, as part of the constructor, takes in a UnitOfWork object. I then created an abstraction to those repositories with services layers. Each layer creates a UnitOfWork that is then passed to its respective repository.
In my service layer, should I only be opening one UOW that can be used by all the services I have created? I haven’t run into any issues, yet, but wanted to know if what I am doing can possibly cause issues.
As a note, in my web application, I am only working with one entity type at a time when inserting an updating data. My concern came when I had to instantiate one service for the main entity and then possibly another service to read in static data that comes from a configuration table in the database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以在单个请求处理中拥有所需数量的工作单元实例。工作单元代表单个逻辑操作。
为了简单起见（在大多数情况下这就足够了），开发人员通常为每个请求使用一个新的单一工作单元，因为每个请求通常代表一个逻辑操作。但您可能会发现这还不够的场景。在这种情况下，您将需要多个工作单元，并且可能还需要多个存储库（每组与一个工作单元相关联）。
You can have as many unit of work instances as you need within single request processing. Unit of work represents single logical operation.
For simplicity (and in most cases it is enough) developers usually use a new single unit of work for each request because each request usually represents one logical operation. But you can find scenarios where this will not be enough. In such case you will need multiple unit of works and probably also multiple repositories (each set associated with one unit of work).
如果您有多个工作单元，您最终会遇到问题，因为如果您尝试将一个上下文（工作单元）中的实体与另一个上下文中的实体相关联，则会发生更改跟踪器冲突。
假设您有一个名为 .Task 或类似名称的业务层，每个任务都应该实例化一个工作单元并将其传递到它调用的存储库中，因为它是任务，而不是存储库，它应该知道如何将实体组合在一起。
如果未提供，默认情况下让存储库默认为 UOW 是可以的 - 但这可能会导致任务编码松懈，最终您将创建一个带有 UOW 的存储库，然后在具有自己的 UOW 的内容中使用其输出。
还要避免一种常见的静态工作单元 - 因为再次强调，应该由任务（而不是存储库或模型）来决定何时应应用更改。
If you have multiple units of work you WILL eventually have problems, because if you try to relate an entity from one context (unit of work) to an entity from another context, you'll have a change tracker collision.
Assuming you have a business layer called .Task or some such, each Task should instantiate a unit of work and pass it into the repositories it calls, since it is the task, not the repo, which should know how entities are to be brought together.
It's ok to have a repo default a UOW by default if one isn't provided - but that can lead to lax task coding where you end up creating a repo w/o a UOW then using its output in something that has its own UOW.
Avoid one common static unit of work, as well - since again, the task, not the repo or the model, should be deciding when changes should be applied.
不可以，您一次只能打开一个 UoW。我建议使用 Factory 为每个 HTTP 请求提供一个 UoW 实例。
您可以在此处找到示例实现：实体框架 4 CTP 4 / CTP 5 通用存储库模式和可单元测试
No, you should only have a single UoW open at a time. I would recommend using a Factory to provide a single instance of your UoW per HTTP Request.
You can find a sample implementation here: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable