unit-of-work

I'm facing an issue today and I'm unable to solve it, I searched a lot and can't get into a solution, please help me if you can. I'm implementing a MVC application which uses EF + Repository Pattern + Unit Of Work with Autofac as the Dependency Injector. I was able to work with one DbContext class, but I'm facing a situation where I need to use another DbContext instance (which access another database with another user credentials) Let me explain better: I have EntityA which comes from database A (and have a DatabaseA_Context class). So I need a EntityB, which comes from database B (with its

I'm looking for some advices about the unit of work pattern. Is the commit on the unit of work called multiple times or just one time and then leaving the object for garbage collection? Is it a good idea to inject the unit of work play or should I pass it around in method call when asking objects to perform some work? Instances of types that implement the unit of work pattern usually have a single owner that needs to control its lifetime. Methods like Commit , Open , Close , and Dispose are often strong signals that a type should be controlled explicitly (or placed behind an abstraction if

I'm thinking about making my own IUnitOfWork implementation for an NHibernate persistence layer. It seems that the right way to do this would be to have the ISession and the ITransaction instantiated in the constructor, and then disposed in the destructor or the Dispose() method. Of course, if someone invokes the Save() method, then the ISession would be flushed and the ITransaction would be complete, so after calling Save() , there would not be a valid open transaction to Save() again... unless I committed the first transaction and immediately opened another, new transaction. But is this a

I was searching the net up and down and I didn't manage to find a suitable design for my application. I am looking for Repository+UnitOfWork pattern that will manage connections and dispose them automatically when done. I need to support both web application where each request will have its own UnitOfWork and windows application where each thread will have its own UnitOfWork. I need the patters to dispose automatically the UnitOfWork whrn request/thread is done. I also would like to support rolback in case of exception. Right now I use StructureMap so I don't care to continue use it in the

I am a bit lost right now... I've never seen this much divergent information regarding solution to the problem. But let us start from the beginning. I am using ASP.NET MVC with Repositories injected to Controllers, thanks to the Ninject. I have 2 simple Entities: Admin with a list of created blog entries and Entries with one virtual Admin field. Admin: public class Admin { [Key, ScaffoldColumn(false)] public int Id { get; set; } [Required(ErrorMessage = "Zły login.")] [StringLength(20), MinLength(3)] [RegularExpression(@"^[a-zA-Z0-9]*$", ErrorMessage = "Special characters are not allowed.")]

I'm thinking of the options in regards to implementing a single unit of work for dealing with multiple datasources - Entity framework. I came up with a tentative approach - for now dealing with a single context - but it apparently isn't a good idea. If we were to analyze the code below, would you consider it a bad implementation? Is the lifetime of the transaction scope a potential problem? Of course if we wrap the transaction scope with different contexts we'd be covered if the second context.SaveChanges() failed... using System; using System.Collections.Generic; using System.Linq; using