在不同的datacontexts不同的方法LINQ to SQL中添加/更新 [英] Linq to sql add/update in different methods with different datacontexts

问题描述

我要的方法，add（）和更新（），这两个创建一个DataContext并返回创建/更新的对象。

I have to methods, Add() and Update() which both create a datacontext and returns the object created/updated.

在我的单元测试我先打电话Add（）方法，做一些东西，然后调用Update（）。问题是，更新（）失败，异常：

In my unit test I call first Add(), do some stuff and then call Update(). The problem is that Update() fails with the exception:

  System.Data.Linq.DuplicateKeyException: Cannot add an entity with a key that is already in use..

我理解的问题，但想知道该怎么做吧？我读过一些关于如何处理多个对象的DataContext从我所听到这种方式确定。

I understand the issue but want to know what to do about it? I've read a bit about how to handle multiple datacontext objects and from what I've heard this way is OK.

据我所知，实体仍连接到DataContext中添加（），但我需要找出如何解决？

I understand that the entity is still attached to the datacontext in Add() but I need to find out how to solve this?

在此先感谢

推荐答案

要坦率地说，这是从设计的角度不对的旋转起来<$ C $℃的>的DataContext 实例添加和更新方法。

To be blunt, it's wrong from a design perspective to be spinning up DataContext instances in Add and Update methods.

据推测，这些方法都是在某种库类的 - 在这种情况下，库应该预先存在的的DataContext 进行初始化， 。一般通过构造函数传递

Presumably these methods are in some kind of Repository class - in which case, the repository should be initialized with a pre-existing DataContext, generally passed in through the constructor.

如果你设计你的资料库这种方式，你就不必担心这个问题：

If you design your repository this way, you don't have to worry about this problem:

public class FooRepository
{
    private MyDataContext context;

    public FooRepository(MyDataContext context)
    {
        if (context == null)
            throw new ArgumentNullException("context");
        this.context = context;
    }

    public void Add(Foo foo)
    {
        context.FooTable.InsertOnSubmit(foo);
    }

    public void Update(Foo foo)
    {
        Foo oldFoo = context.FooTable.Single(f => f.ID == foo.ID);
        oldFoo.Bar = foo.Bar;
        oldFoo.Baz = foo.Baz;
    }
}

然后，从那里你执行你的更新：

Then, from whence you perform your updates:

Foo fooToSave = GetFooFromWherever();
using (MyDataContext context = new MyDataContext(...))
{
    FooRepository repository = new FooRepository(context);
    repository.Save(fooToSave);
    context.SubmitChanges();
} // Done

这模式可以使用和重用，并可以结合多个库到一个单一的交易;你永远不会遇到任何问题，它。这是怎样的的DataContext ，它封装单位按工作模式，实际上意味着要使用。

This pattern can be used and reused, and you can combine multiple repositories into a single "transaction"; you'll never run into any problems with it. This is how the DataContext, which encapsulates a Unit-of-Work pattern, was actually meant to be used.

顺便说一下，在设计资源库时，这是常见的，试图抽象掉繁琐的插入 / 更新语义，只是揭露一个保存方法：

Incidentally, when designing a repository, it's common to try to abstract away the cumbersome Insert/Update semantics and just expose a Save method:

public void Save(Foo foo)
{
    if (foo.ID == default(int))
    {
        Insert(foo);
    }
    else
    {
        Update(foo);
    }
}

你不是总是不必担心这样无论您是否已经插入你的富。

是可能的到强制LINQ to SQL的进入处理的独立的实体，但好运气得到它处理那些的已的连接到的不同的上下文的实体。而且即使在分离的情况下，这真的很麻烦，你需要有对所有表/实体时间戳字段或先从版本检查/自动同步性能搞乱 - 这是不值得的海事组织，只是设计你的仓库来使用的有一个的每个实例的上下文，并分享彼此之间的上下文实例。

It is possible to coerce Linq to SQL into dealing with detached entities, but good luck getting it to deal with entities that are already attached to a different context. And even in the detached case, it's really quite cumbersome, you need to have timestamp fields on all your tables/entities or start messing with the version check/autosync properties - it's not worth it IMO, just design your repositories to use one context per instance and to share context instances between each other.

这篇关于在不同的datacontexts不同的方法LINQ to SQL中添加/更新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！