Welcome to the Lounge
For lazing about and discussing anything in a software developer's life that takes your fancy.
The Lounge is rated PG. If you're about to post something you wouldn't want your kid sister to read then don't post it. No flame wars, no abusive conduct and please don't post ads.
Technical discussions are welcome, but if you need specific help please
use the programming forums.
|
|
 |

|
I added some 50 classes to an EF model, with a single DbContext. This is the first EF model of any size I've ever built, and, of course, I have to learn everything about EF from scratch.
After wrapping a couple tables in their own copy of the Repository pattern, I discovered, rather annoyingly, that having multiple instances of said context searching for and adding new items in a relationship presents some problems, because you can't have a single entity tracked by more than one instance of the DbContext managing it. For example, in two seperate repositories, having a context instance creating a new entity and then adding it to a navigation property of a host entity that was dug up by another context instance in a seperate repository. So then how do you get two repositories to share the same context??
Hmmm... What to do, what to do...
After 18 hours of beating my head against a wall, nearly knocking myself unconscious, trying to come up with a solution to this little problem, the SIMPLEST idea finally crossed my path: Unit Of Work.
Why, oh WHY, did this not occur to me sooner!?!?! It's a simple pattern really. Wrap your repositories in a UnitOfWork class that maintains a context instance and hands that context to any repository added to the UnitOfWork class.
Grrrrrrrrrr.
But, on the plus side, I also found a way to create generic Repository and generic UnitOfWork classes, saving myself from writing about 50+ classes!
|
|
|
|
 |
|
|
General
News
Suggestion
Question
Bug
Answer
Joke
Rant
Admin