0

我正在使用 C# 和 EF 4.0，在我的应用程序中，我有一个存储库，它连接到数据库并执行我需要的所有操作（插入、更新、删除以及确保信息连贯的逻辑）。

在某些情况下，我可能需要更新许多具有相同信息的寄存器，所以如果我有一个允许一次更新多个寄存器的方法，那就更舒服了。在这种方法中，如果一个寄存器有问题（唯一约束、不存在的 FK ......）我可以分离实体并使用下一个寄存器重试。

但是我发现这种方法存在一些问题：

1.- EF 如何是一个事务，如果只有一个寄存器有问题，任何一个都会更新。

2.-如果我只更新一个寄存器，我可以分析原因是不是一个FK不存在，唯一的约束等等。如果该方法更新了很多寄存器，并且存在很多不同问题的寄存器，我无法将问题的原因告知用户，或者更难分析和告知用户。

3.-也许，所以该方法需要更多时间，因为它使用服务器的CPU资源更长，所以其他用户可能必须等到一些资源被释放。确实，这些方法非常快，但如果我使用只能更新一个寄存器的方法，则资源可以更好地在更多用户之间共享（更好的多任务？）。

优点：

1.- 我只创建一个数据上下文，所以我认为这更有效，因为我不需要在我要更新的每个寄存器中创建和销毁它（如果我调用 N 次只更新一个的方法，则会发生这种情况立即注册）。

所以我的问题是，当我需要更新许多寄存器时，更好的一种方法是接收作为参数的寄存器列表并一次性更新所有寄存器，或者更好的方法是一次只能更新一个寄存器并且是客户端谁需要调用该方法 N 次？

谢谢。

4

1 回答 1

0

看一下工作单元模式。您的存储库将包含一次仅更新一个寄存器的方法，但您的业务逻辑将具有一个接受寄存器列表、创建工作单元实例并为每个寄存器调用一次存储库更新方法的方法。

业务逻辑看起来像：

public class MyEntityLogic
{
    ...

    public MyEntity Save(List<MyEntity> entities)
    {
        MyEntity result = null;

        using (var uow = new UnitOfWork(MyContext))
        {
            foreach (var entity in entities)
                result = MyRepository.Save(entity);
            uow.Save(); // This will actually make the changes in the DB.
        }

        return result;
    }

    ...
}

虽然存储库只有一个只接受一个寄存器的方法：

public class MyEntityRepository
{
    ...

    public MyEntity Save(MyEntity entity)
    {
        // Update the context if using EF or execute the query.
        ....
    }

    ...
}

当然，您应该添加异常处理。您还可以让您的存储库控制事务逻辑（提交、回滚、开始事务......）。无论如何，UOW 的正确实现不只一种。

然后，您的 UnitOfWork 课程将处理您的“交易”。如果您有关系等，您甚至可以对几种类型的实体使用相同的 uow ...

关于 UOW 的一些链接：

工作单元实施

http://www.codeproject.com/Articles/576681/UnderstandingplusandplusImplementingplusRepository

https://codereview.stackexchange.com/questions/5556/entity-framework-with-repository-and-unit-of-work-pattern-and-poco-architecture

玩得开心！

于 2013-07-21T08:48:46.400 回答