I am using Entity Framework 5 with Code First approach and using Fluent API for Entity configuration. My project has one particular Product Entity which gets half of its dat
Today I found an event in the Entity Framework that seems to be what I am looking for. ObjectContext.ObjectMaterialized Event. Apparently, DbContext implements IObjectContextAdapter which in-turn exposes the ObjectContext. From there I can subscribe to the ObjectMaterialized event.
MSDN Reads: Occurs when a new entity object is created from data in the data source as part of a query or load operation.
The following code demonstrates how I used the ObjectMaterialized event to solve my problem in which one of my preferences was to have a central point to place the WCF client access logic.
// seperate assembly - does not use Domain.Repositories assembly
namespace Domain.Models
{
// the data contract
[DataContract]
public class ProductInventoryState
{
[DataMember]
public int StockStatus { get; set; }
[DataMember]
public IEnumerable<String> SerialNumbers { get; set; }
// etc....
}
// the entity
public class Product
{
public Guid Key { get; set; }
public string ProductCode { get; set; }
public ProductInventoryState InventoryState { get; set; }
// etc....
}
}
// seperate assembly - uses Domain.Models assembly
namespace Domain.Repositories
{
public class MainRepository : DbContext
{
public MainRepository()
{
((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized += ObjectContext_ObjectMaterialized;
}
protected void ObjectContext_ObjectMaterialized(object sender, ObjectMaterializedEventArgs e)
{
if (e.Entity == null)
return;
if (e.Entity is Product)
{
Product product = (Product)e.Entity;
// retrieve ProductInventoryState from 3rd party SOAP API
using (ThirdPartyInventorySystemClient client = new ThirdPartyInventorySystemClient())
{
// use ProductCode to retrieve the data contract
product.InventoryState = client.GetInventoryState(product.ProductCode);
}
}
}
}
}
1.) You can write your own EF Provider (but that is no small task)
2.) You can attach items to the context but not save them.
The entity.State can be set as Not modified after attaching. You could also remove such entries from Context prior to save changes
3) You can Write a repository fascade that check EF and Checks location 2 and combines the result.
On the question of navigation properties. You would need to specify these very carefully to avoid issues. Not lazy loaded or not even modelled.
I wouldnt try and mix them personally.
You can tell EF to ignore some properties.
So you can have a Nice original POCO, but only model the bits that are on the DB.
The POCO would then collect the rest.
I use a fascade with events myself to act on KEY methods on a context/DBset. So I can trigger events on attach , get, save etc.
good luck