Re: Help with NewEntity in EFCodeFirst wrapper

I think the issue is this: If you create a new entity and automatically add child objects in the constructor, they are then automatically marked as EntityMode.Added. If you then assign values to that object, that won't change the entity state, so they will always be assumed to be added even if you assign an ID explicitly.

The way that this can be fixed is to ensure you assign an entity retrieved from the DbContext in the first place, and not just assign the values to the new entity that was added implicitly.

Here's an example of an order placed with a previously created customer attached (which is similar to what you're doing):

[TestMethod]publicvoid AttachWithChildExistingTest()
{var orderBo = new busOrder();var custBo = new busCustomer(orderBo); // share context// same as this to share context//custBo.Context = orderBo.Context;var order = orderBo.NewEntity();
    order.OrderId = StringUtils.NewStringId();// this is easiest and most efficient//order.CustomerPk = 1;// manually load customer instance from contextvar cust = custBo.Load(1);//orderBo.Context.Customers.Find(1);
    cust.Updated = DateTime.Now; // make a change
    order.Customer = cust;            // add a new line item
    order.LineItems.Add(new LineItem() 
                        { 
                            Description = "Cool new Item",
                            Price = 40M,
                            Sku="COOLNEW",
                            Quantity = 1,
                            Total = 40m
                        });

    Assert.IsTrue(orderBo.Save(), orderBo.ErrorMessage);

}

Note that for the bus object to work the context needs to be shared. Typically operations like this would actually occur in the business object so the BO method would do the composition typically and you might not actually use two business objects to perform such an operation.

FWIW, I tend to add an overloaded constructor for sharing the context between bus objects:

public class busCustomer : EfCo

publicclass busCustomer : EfCodeFirstBusinessBase<Customer,WebStoreContext>
    {public busCustomer()
        { }public busCustomer(IBusinessObject<WebStoreContext> parentBusinessObject) : base(parentBusinessObject)
        { }
    }publicclass busOrder : EfCodeFirstBusinessBase<Order, WebStoreContext>
    {public busOrder()
        { }public busOrder(IBusinessObject<WebStoreContext> parentBusinessObject) : base(parentBusinessObject)
        { }
    }

There's no code here but unfortunately constructors of child objects don't automatically inherit their base constructors so these constructors have to be explicitly implemented.

BTW, for your models I highly recommend that you add an integer ID for foreign keys in addition to the entity itself. Yes that's not purely clean for OO, but it makes a lot of things vastly easier. Updates among them because instead of to explicitly having to load and assign object you can just update the ID. So if customer is not updated you can simplify the code to:

[TestMethod]publicvoid AttachWithChildExistingAndCustIdTest()
{var orderBo = new busOrder();var order = orderBo.NewEntity();
    order.OrderId = StringUtils.NewStringId();// this is easiest and most efficient
    order.CustomerPk = 1;// add a new line item
    order.LineItems.Add(new LineItem()
    {
        Description = "Cool new Item",
        Price = 40M,
        Sku = "COOLNEW",
        Quantity = 1,
        Total = 40m
    });

    Assert.IsTrue(orderBo.Save(), orderBo.ErrorMessage);
}

In short the important thing to remember for EF is that EF tracks state of an entity and unless you explicitly change that state either explicitly or by assigning a different entity that has its own state that state stays with the entity.

This stuff is confusing I agree, and I think it sucks that EF isn't smart enough to figure out that if you assign an object with an ID that exists that it should update the record regardless especially since EF knows what the key is in the model, but that's just how EF works. Everything is tied to the context.

It's not obvious but it's also not difficult to work around - ultimately I think the only time this behavior becomes 'weird' is in Web update scenarios when you're model binding. The trick is to always load up fully loaded entities when doing updates - never bind to empty ones unless you are indeed using a new record for everything.

It may seem that using the business object is more work, but there's good reason to use it IMHO: It abstracts the db logic considerably plus gives you many hook points to add additional functionality easily. So when you save you can fire OnBeforeSave() OnAfterSave() etc. or when you call Load() or NewEntity() you can automatically do some calculations on properties. All these are things that you can't do directly with the EF objects. Further the goal is to keep the EF specific code completely out of the front end application. Other than IQueryable() result filtering, the front end application should not ever see any EF specific code. This makes code somewhat more portable. In fact I recently ported a smallish time tracking application from Linq to SQL to EF and was able to easily reuse most of the front end code and even a good chunk of the business object code.

+++ Rick ---

publicvirtual TEntity NewEntity()
        {
            Entity = new TEntity();
            Entity = Context.Set<TEntity>().Add(Entity) as TEntity;

            OnNewEntity(Entity);

            if (Entity == null)returnnull;return Entity;
        }

public ActionResult test3()
{
    var existingQuoteBO = new busQuote(9001); // Loads existing Quote# 9001
    var newQuoteBO = new busQuote();

    quote newQuote = newQuoteBO.NewEntity();
    AutoMapper.Mapper.Map(existingQuoteBO.Entity, newQuote); // Copy existing values to newly created Quote
    newQuote.LineItems = new List<quoteitem>(); // Blank out the QuoteLineItems collection that was copied over

    newQuoteBO.Save();  <---See error message below.return RedirectToAction("edit", "quotes", new { id = newQuote.id });

}

Error: Violation of PRIMARY KEY constraint 'PK_customers_1'. Cannot insert duplicate key inobject'dbo.customers'.
The statement has been terminated.}	Westwind.BusinessFramework.EfCodeFirst.EfCodeFirstBusinessBase<MVC4_App1_EFData.Models.quote,MVC4_App1_EFData.QuoteContext> {MVC4_App1_EFData.busQuote}
Surely the EF thing is smart enough not to create a new Customer.???

So, if I skip the NewEntity() technique, and use this approach instead:
var newQuote = new quote();

Then copy the properties from the existing Quote to this new Quote (again using AutoMapper), then I call:
newQuoteBO.Context.Quotes.Add(newQuote);
newQuoteBO.Save()
then it works just fine!!!

So, clearly there is something about using NewEntity() that I am missing.