I have a WCF-service with one business component where I put my business logic and one dataaccess component where I put my Entity Framework model and methods against that. I want to seperate these to be able to mock my DAC-methods in unit tests of my business logic and also for reusability of the DAC-methods.
What I'd like to do is basically this. I want to call one method to update data and then another method to read the updated data. Below is the easiest example of this.
The problem is this. Sometimes, almost never, the data you read in one context will not have the update you just did in the other context.
As you all know the bugs that almost never appears are the worst.
Sure, it's easy enough to code around, ie make the DAC-methods more complex or move the EF-model to the BC, it but I want to keep my DAC-methods simple. They do one small thing and that's it.
Code: Select all
Businesscomponent:
public Entity SaveEntity(Entity entity)
{
var dac = new DataAccessComponent();
// First save
dac.UpdateEntity(entity);
// Then read and return updated data
return dac.ReadEntity(entity.key);
}
DataAccessComponent:
public void UpdateEntity(Entity entity)
{
using (context = new ....)
{
// Do my updates
context.SaveChanges();
}
}
public Entity ReadEntity(Key key)
{
using (context = new ....)
{
var entity = context.Entity.First(x => x.Key == key);
return entity;
}
}
Should I use a singleton context? But I've read about problems with that approach as well. Memory leaks and what have you. Or is there a way of making sure that the data gets committed to the database at once?