would you mind to discuss the significance of unit of work pattern and its advantage. anyone can explain with small sample code the advantage of unit of work pattern. thanks
The Unit of Work pattern is actually implemented by modern high-end ORMs such as Entity Framework and NHibernate themselves. These ORMs keep track of all the entities that you have added, deleted or modified, and then when you call DbContext.SaveChanges
(Entity Framework) or ISession.Flush (NHibernate), persists them to the database.
You sometimes see people wrapping Entity Framework or NHibernate in a class that implements an IUnitOfWork interface and consists of nothing more than a direct call into DbContext.SaveChanges/ISession.Flush. This isn't actually an example of the Unit of
Work pattern but an abstraction layer around it. It is almost never necessary and usually only exists because That Is How We Do Things™.
This is pretty well explained IMO in the earlier article. They talk about the approach which is to send individual statements to perform each and every udpate separately one after the other and then the code that follows is using Entity Framework when you
built an object graph for all changes and then save them as a single "unit" (it does the same thing behind the Hood but it is abstracted away and done within as single transaction for you).
So as noted by others, if using Entity Framework you already use the "unit of work" pattern.
Participant
1347 Points
2399 Posts
Why unit of work is required
Feb 06, 2015 02:33 AM|mou_inn|LINK
would you mind to discuss the significance of unit of work pattern and its advantage. anyone can explain with small sample code the advantage of unit of work pattern. thanks
Member
430 Points
399 Posts
Re: Why unit of work is required
Feb 06, 2015 04:05 AM|jammycakes|LINK
The Unit of Work pattern is actually implemented by modern high-end ORMs such as Entity Framework and NHibernate themselves. These ORMs keep track of all the entities that you have added, deleted or modified, and then when you call DbContext.SaveChanges (Entity Framework) or ISession.Flush (NHibernate), persists them to the database.
You sometimes see people wrapping Entity Framework or NHibernate in a class that implements an IUnitOfWork interface and consists of nothing more than a direct call into DbContext.SaveChanges/ISession.Flush. This isn't actually an example of the Unit of Work pattern but an abstraction layer around it. It is almost never necessary and usually only exists because That Is How We Do Things™.
Participant
1347 Points
2399 Posts
Re: Why unit of work is required
Feb 06, 2015 06:34 AM|mou_inn|LINK
it would be better if u would explain the whole things with sample in such a way anyone can understand who never use unit of work before. thanks
All-Star
41930 Points
14220 Posts
Re: Why unit of work is required
Feb 06, 2015 06:44 AM|PatriceSc|LINK
Hi,
I would suggest http://rlacovara.blogspot.fr/2009/04/entity-framework-patterns-unit-of-work.html which seems a simple and straightforward explanation.
All-Star
37441 Points
9077 Posts
Re: Why unit of work is required
Feb 06, 2015 07:58 AM|AidyF|LINK
He's telling you not to bother implementing Unit of Work if you use Entity Framework :)
Member
430 Points
399 Posts
Re: Why unit of work is required
Feb 06, 2015 08:09 AM|jammycakes|LINK
No, I'm saying not to abstract UnitOfWork if you're using an ORM that implements it already.
Participant
1347 Points
2399 Posts
Re: Why unit of work is required
Feb 06, 2015 09:35 AM|mou_inn|LINK
@AidyF: thanks for reply.
Entity Framework has any built-in mechanism for unit of work ?
briefly discuss what kind of purpose solved by unit of work ?
thanks
All-Star
37441 Points
9077 Posts
Re: Why unit of work is required
Feb 06, 2015 09:36 AM|AidyF|LINK
The DBContext acts as a unit of work. As you make changes it tracks these changes and when you Submit the changes they all get done as one.
All-Star
41930 Points
14220 Posts
Re: Why unit of work is required
Feb 06, 2015 10:50 AM|PatriceSc|LINK
This is pretty well explained IMO in the earlier article. They talk about the approach which is to send individual statements to perform each and every udpate separately one after the other and then the code that follows is using Entity Framework when you built an object graph for all changes and then save them as a single "unit" (it does the same thing behind the Hood but it is abstracted away and done within as single transaction for you).
So as noted by others, if using Entity Framework you already use the "unit of work" pattern.