Simple transactions in EF4.0 POCO with UnitOfWork pattern and ApplicationBus

i recently ran into the surprising behaviour of EF4, where after adding an entity to a context it is not available for querying (well, you need to make your queries aware, that you might be searching in the memory) unless SaveChanges() is called.

Let me explain a bit our scenario: We are using the UnitOfWork pattern with EF 4.0 and POCO objects. We recently decided to implement a Message Bus, where we would implement in the message handlers most of the application logic.

The problem i ran into was when i was passing around my UnitOfWork(a context wrapper in our case) in the messages. For example I have the logic of printing a Barcode, when i do it, it should change the Printed Counter in the DB. The printing can happen ad hoc for an existing package, or can be done automatically when creating a special type of a package. I pass over the UnitOfWork, and then i look for a barcode with:

public void Handle(IBarCodePrintMessage message)
{
    if (message.UnitOfWork == null)
        using (var uow = factory.Create<IUnitOfWork>)
        {
             Handle(message, uow);
             uow.Commit();
        }
    else
        Handle(message, message.UnitOfWork);
}

void Handle(IBarCodePrintMessage message, IUnitOfWork uow)
{
    // the barcode with the PackageID is in the context or in the db
    var barCode = uow.BarCodes.Where(b => b.PackageID == message.PackageID).SingleOrDefault();

    barCode.IncreasePrintCount(); // this might be ac开发者_如何学JAVAtually quite complex, and sometimes fail
    printingServices.PrintBarCode(barCode);
}

My problem is, that if the Barcode was added within this same uow, and there was no Commit yet, then it is not found.

This is the simpliest example, we have tons of code that was doing its own commit, and now all this needs to go under one transaction.

I have a couple of questions actually:

1) I was thinking of somehow hacking my IUnitOfWork, to return a set of objects, that might be either in memory (not commited changes), or in the DB (if not retrieved yet). This is actually a behaviour i would expect my UnitOfWork, tell me what is the last state i am at, even though i didnt commit yet, and not to give me the db state. For the db state i can create another context.

Anyways this seems to be quite tricky, cause i would need to implement my own type of entity collection, all the extendsion methods on it (where, select, first, groupby, etc), then to get it to work the IQueryable way (meaning it doesnt list the tables straight away), and then find a way to match up the locally cached entities and the retrieved ones. To me this seems to be a generic problem, and i would believe there is already an implementation out there, just not sure where.

2) another option is to introduce manual transactions. I tried it against SQLCE4.0 and it might solve the issue (call savecontext very often, so the entities are queriable from the db, and then if any error occurs, rollback the transaction), but i have big doubts. There might be different threads runnign different transactions at the same time, not sure how would they interact if one rolls back.

Also we are using SQL CE 4.0 and SQL Express 2008 (both, and can be switched dynamically). Starting to handle transactions this way seems to bring in the DTC, which - i read everywhere - is quite a heavy thing, and i would prefer to avoid. Is there a way to use transactions in an easy way without the risk of leveraging them to the DTC?

3) Does anyone have any other options or ideas on how to go about this problem?

---

You can query context for not persisted entities.

var entity = context.ObjectStateManager
                    .GetObjectStateEntries(EntityState.Added)
                    .Where(e => !e.IsRelationship)
                    .Select(e => e.Entity)
                    .OfType<BarCode>()
                    .FirstOrDefualt(b => b.PackageId == message.PackageId);

You can make this more generic and incorporate it into your UoW logic where you will first check your unsaved entities and if you not find the entity you will query the database.

Anyway if you know that you create a new barcode which will be needed in the following processing it should be passed in the "message" as property exposed on your interface.