Question

I am looking for a simple way to hydrate a related object. A Note belongs to a Document and only owners of a Document can add Notes so when a user tries to edit a Note, I need to hydrate the related Document in order to find out if the user has access to it. In my Service layer I have the following:

public void editNote(Note note)
    {
        // Get the associated Document object (required for validation) and validate.
        int docID = noteRepository.Find(note.NoteID).DocumentID;
        note.Document = documentRepository.Find(docID);

        IDictionary<string, string> errors = note.validate();
        if (errors.Count > 0)
        {
            throw new ValidationException(errors);
        }

        // Update Repository and save.
        noteRepository.InsertOrUpdate(note);
        noteRepository.Save();
    }

Trouble is, noteRepository.InsertOrUpdate(note) throws an exception with “An object with the same key already exists in the ObjectStateManager.” when the repository sets EntityState.Modified. So a number of questions arise:

1. Am I approaching this correctly and if so, how do I get around the exception?
2. Currently, the controller edit action takes in a NoteCreateEditViewModel. Now this does have a DocumentID field as this is required when creating a new Note as we need to know which Document to attach it to. But for edit, I cannot use it as a malicious user could provide a DocumentID to which they do have access and thus edit a Note they don’t own. So should there be seperate viewmodels for create and edit or can I just exclude the DocumentID somehow on edit? Or is there a better way to go about viewmodels such that an ID is not required?
3. Is there a better way to approach this? I have read that I should just have a Document repository as an aggregate and lose the Note repository but am not sure if/how this helps.

I asked a similar question related to this but it wasn’t very clear so hoping this version will allow someone to understand and thus point me in the right direction.

EDIT

Based on the information provided by Ladislav Mrnka and the answer detailed here: An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key, it seems that my repository method need to be like the following:

public void InsertOrUpdate(Note note)
    {
        if (note.NoteID == default(int)) {
            // New entity
            context.Notes.Add(note);
        } else {
            // Existing entity
            //context.Entry(note).State = EntityState.Modified;
            context.Entry(oldNote).CurrentValues.SetValues(note);
        }
    }

But how do I get the oldNote from the context? I could call context.Entry(Find(note.NoteID)).CurrentValues.SetValues(note) but am I introducing potential problems here?

Answer 1

Am I approaching this correctly and if so, how do I get around the exception?

I guess this part of your code loads the whole Node from the database to find DocumentID:

int docID = noteRepository.Find(note.NoteID).DocumentID;

In such case your InsertOrUpdate cannot take your node and attach it to context with Modified state because you already have note with the same key in the context. Common solution is to use this:

objectContext.NoteSet.ApplyCurrentValues(note);
objectContext.SaveChanges();

But for edit, I cannot use it as a malicious user could provide a DocumentID to which they do have access and thus edit a Note they don’t own.

In such case you must add some security. You can add any data into hidden fields in your page but those data which mustn’t be changed by the client must contain some additional security. For example second hidden field with either signature computed on server or hash of salted value computed on server. When the data return in the next request to the server, it must recompute and compare signature / hash with same salt and validate that the passed value and computed value are same. Sure the client mustn’t know the secret you are using to compute signature or salt used in hash.

I have read that I should just have a Document repository as an aggregate and lose the Note repository but am not sure if/how this helps.

This is cleaner way to use repositories but it will not help you with your particular error because you will still need Note and DocumentId.