Geeks With Blogs

News Please visit me at my new blog!!

profile for Aligned at Stack Overflow, Q&A for professional and enthusiast programmers
"free in Christ Jesus from the law of sin and death." Romans 8:2 (ESV) Check out the Falling Plates video on YouTube.
more about the Gospel
And then listen to Francis Chan speaking at LifeLight in SD.



Programming and Learning from SD

I didn’t understand why I would want to use the Unit of Work pattern before I ran into this. I had a ManagerBase class that had an IRepository. (The managers implement ManagerBase which have a private Repository that follows Juans approach http://geekswithblogs.net/JuansAndZeros/archive/2012/10/03/building-a-repository-pattern-against-ef-5-model-first.aspx)The Repository had the context and saveChanges method. This means that each “Manager” I had, contained a different instance of the context. This all worked well until I tried to save into a linking table. This code shows how I tried to update the users assigned to a certain Layout. Layout has a ICollection<UserProfile> property of UserProfiles as generated by the EF Power Tools from our database.

var assignedUserProfiles = this._userProfileManager.GetAll().Where(u => assignedList.Contains(u.UserId));
layoutMatch.UserProfiles = assignedUserProfiles.ToList();
this._layoutManager.Update(layoutMatch, layoutMatch.LayoutId); 

It creates a new record in UserProfiles and in the LayoutUsers, even through the UserProfile object in assignedUserProfiles had the UserId (PK) set.

The state was always "Added" when Debugging the Repository, before the SavedChanges call.

I believe this is because the userProfileManager and the layoutManager have different contexts.

This StackOverflow question shows the same problem and Ladislav Mrnka mentions using a Unit of Work pattern to handle this problem, which links to this question.

One last link: http://codereview.stackexchange.com/questions/14226/generic-repository-and-unit-of-work-code

Once I moved the context into the ManagerBase and I pass in that same context to both Repositories, the save worked as expected. So I now basically have a UnitOfWork and Repository pattern after all, we just call it a “Manager” instead/

Posted on Tuesday, March 12, 2013 4:21 PM Entity Framework , Repository Pattern , Unit of Work | Back to top


Comments on this post: Here’s why the Unit of Work is needed

# re: Here’s why the Unit of Work is needed
Requesting Gravatar...


I am thinking after several days... is really necessary to use UoW and Repository patterns with Entity Framework 5 and upper? I mean, the way of use and objectives of Repository Pattern are already achieve with EF (except for those you have several data sources)... and Unit of Work is used to set individual operations... that with EF internally is achieve too... So I just want to ask if at the point of view of Architecture software design is an over engineering implement those patters or not!

I know it sounds pretty silly, but I just want to make things simplest and professionally.

Thank you!!!




http://commodityonlinetips.in/
Left by Rishima Hazi on Jun 29, 2015 6:35 AM

# re: Here’s why the Unit of Work is needed
Requesting Gravatar...
Thanks Rishima for your comment. At my company we've been moving away from repositories. There is a lot of extra code that needs to be written and tested. We've been talking about using a service layer/module that has business logic and EF data context connection.
Left by Kevin on Jul 02, 2015 11:52 AM

# re: Here’s why the Unit of Work is needed
Requesting Gravatar...
I am thinking after several days... is really necessary to use UoW and Repository patterns with Entity Framework 5 and upper? I mean, the way of use and objectives of Repository Pattern are already achieve with EF (except for those you have several data sources)... and Unit of Work is used to set individual operations... that with EF internally is achieve too... So I just want to ask if at the point of view of Architecture software design is an over engineering implement those patters or not!

I know it sounds pretty silly, but I just want to make things simplest and professionally.

Thank you!!!
Regards
MCX Trading Tips
Left by MCX Tips on May 14, 2016 2:35 AM

# re: Here’s why the Unit of Work is needed
Requesting Gravatar...
About a year after I wrote this post we had a similar discussion at our company. "Isn't EF really the repository already?" I wasn't completely sold as it was still really hard to mock EF for unit testing. Since then, with EF 6+, Microsoft has made testing much easier. Now I don't use the repository (too much complexity as MCX Tips mentioned for most applications. Thanks for the comment
Left by Kevin on May 17, 2016 6:36 AM

# re: Here’s why the Unit of Work is needed
Requesting Gravatar...

I am thinking after several days... is really necessary to use UoW and Repository patterns with Entity Framework 5 and upper? I mean, the way of use and objectives of Repository Pattern are already achieve with EF (except for those you have several data sources)... and Unit of Work is used to set individual operations... that with EF internally is achieve too... So I just want to ask if at the point of view of Architecture software design is an over engineering implement those patters or not!

I know it sounds pretty silly, but I just want to make things simplest and professionally.

Thank you!!!
Regards
Intarday Trading tips For Tomorrow
Left by Intraday Tips for tomorrow on Feb 14, 2018 7:06 AM

Your comment:
 (will show your gravatar)


Copyright © Aligned | Powered by: GeeksWithBlogs.net