Unit of Work pattern

static ObjectContext class

This is actually even worse than what you think. The ObjectContext class is not thread safe so even if you manage to get what you think is good synchronization, (without actually locking) you will still be throwing exceptions all the time in a multi-user environment.

The ADO.NET team recommends using a new ObjectContext every time you plan on querying the database. How else could anyone separate their data access classes from each other if this weren't the case?

I think if I make ObjectContext class not-static then this will solve the problem(Not tested yet) but then Unit of Work will not be observed.

Not true at all. The unit of work pattern has nothing to do with having a single repository for an entire application--otherwise, every entity framework tutorial would start you off by showing you how to create your static ObjectContext.

It simply means that if you can't commit the unit of work, the entire commit will be backed out and the entire commit must succeed for it to be successful; it's a single logical transaction.

If you need to keep objects around for the life of the application, look into caching them in a data structure other than an ObjectContext.

I just finished an article today about the repository pattern (with sample implementations).

The thing with most .NET ioc containers is that they support scoping. That is, they can create objects with a limited lifetime. That works very well with HTTP applications since the scope is the same as the lifetime of a HTTP request.

If you use ASP.NET MVC you can combine that with built in features of MVC to trigger the UoW if no errors where detected: http://blog.gauffin.org/2012/06/how-to-handle-transactions-in-asp-net-mvc3/

If you use any other kind of application I usually create a scope by myself (for instance to wrap a command):

using (var scope = MyContainer.CreateChildCointainer())
{
    using (var uow = scope.Resolve<IUnitOfWork>())
    {
        // do something here


        uow.SaveChanges();
    }
}

The thing is that the repositories etc do not have to be aware of the unit of work (if you use databases in .NET). The UoW implementation can make sure that all OR/M or UoW implementation enlists all db commands in the transaction.