EF 4.0 IsAttachedTo extension method and error An object with the same key already exists

I was getting an error

An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key.

After i googled it i found IsAttachedTo extension method there:

Is is possible to check if an object is already attached to a data context in Entity Framework?

here is my code:

foreach (string s in types)
   {
    Subscription subscription = new Subscription { Id = Int32.Parse(s) };

    if (service.repository._context.IsAttachedTo(subscription))
        service.repository._context.Detach(subscription);

    service.repository._context.AttachTo("Subscriptions", subscription); //error here
    horse.Subscriptions.Add(subscription);
    }

But when the subscription with the same key appeared in the foreach loop the extension method IsAttachedTo returning false every time, it is does not detect that there is already such entity attached. And in result i am getting the same error:

An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same 开发者_JAVA技巧 key.

Why it is could be?

What can i do to fix that?

I have little code review for you because your sample code scares me.

You probably read a lot about fancy design patterns and layered architectures and you started to use them yourselves. Unfortunately you missed the main point. What the hell is this?

service.repository._context.XXX

Why do you bother with any service layer or repository layer if they don't encapsulate their logic? Why do you expose repository on the service? Nobody should know about service internal implementation? Even worse why do you expose context on the repository? That spoiled the whole point of the repository!

There are a lot of supporting rules for writing high quality object oriented code. One of this rules is called Law of Demeter. You don't have to follow each rule, you also don't have to follow rules all the time but in case of layered architecture this law is a must.

If you have three layers A -> B -> C the layer A can call methods on the layer B but it doesn't know about C and it cannot reach its methods. If it can, it is not a new layer but it is the same layer as B and the layer A doesn't need to call it through B, it can call it directly.

In your example you have just exposed D to A because A is current layer, B is service, C is repository and D is context.

One more points about your code. There are well known naming conventions. These conventions are not about I like this and you like that but about the fact that framework you are using follow these conventions strictly so using another one to mix your naming convention with framework naming convention make your code look messy.

I'm sorry, If this was only some example code to make your code structuring clear. I just needed to describe how wrong this code is.

Now to your real problem. The method you have referenced from the related question will not work in your case. I think it will work only if you load the subscription from the database. The reason is that the referenced method uses EntityKey (either internally or directly) to get the entity from context but your new entity doesn't have the entity key yet. I expect that calling TryGetObjectStateEntry for your entity will always return Detached. Entity key it is created during attaching or you have to build it manually.

If you want some IsAttachedTo method try this:

public bool IsAttachedTo<T>(this ObjectContext context, T entity) where T : IEntity
{
    return context.GetObjectStateEntries(~EntityState.Detached)
                  .Where(e => !e.IsRelationship)
                  .Select(e => e.Entity)
                  .OfType<T>()
                  .Any(e => e.Id == entity.Id);
}

And make sure that your entity implements helper interface

public interface IEntity
{
    int Id { get; } 
} 

But to be able to detach attached entity you will need:

public T GetAttached<T>(this ObjectContext context, T entity) where T : IEntity
{
    return context.GetObjectStateEntries(~EntityState.Detached)
                  .Where(e => !e.IsRelationship)
                  .Select(e => e.Entity)
                  .OfType<T>()
                  .SingleOrDefault(e => e.Id == entity.Id);
}

You will have to detach instance returned from this method.

Anyway I would start to think why do you need that for the first place because it looks like your architecture has another wrong concept. Why don't you use attached entities directly? If you don't use them why do you even keep the context with them?

It's likely that IsAttachedTo does not compare by the key (Id) but by object identity. Because you create a new Subscription for every item in the loop the objects are all different instances.

Since you seem to have objects with same Id in your types collection but in the end only want to add one object per key into the context you can perhaps make your life easier by filtering out the duplicates in the first place:

var distinctTypes = types.Distinct();
foreach (string s in distinctTypes)
{
    Subscription subscription = new Subscription { Id = Int32.Parse(s) };

    service.repository._context.AttachTo("Subscriptions", subscription);
    horse.Subscriptions.Add(subscription);
}

This way there should be only one object per key which gets attached to the context.