using MVC3, Code First (DbContext)
Is there a way to implement (ideally) a facade or maybe a service layer to decouple MVC3 / EF4.2 WITHOUT also writing up repositories and unit of work? I see repository and unit of work as utterly redundant as they are already in EF. I think people who create those are missing the point but maybe I’m misguided.
Rather, I’d like to see some sort of manager for multiple DbContexts and a Facade making use of that but I can’t for the life of me work it out.
Any ideas? Ideally a pointer to a really good reference project would be perfect.
To be clear, I want [Any Client] -> ([Service] | [Facade]) -> [Model] -> [Data] with no need to incessantly create repository classes.
R.
P.s. This sort of thing was an inspiration: (ObjectContextManager). You can cut out a hell of a lot of code by making that lot reusable and then only worrying about writing your facade classes.
This turned out to be a fascinating detective trail. Reading about the different methods has led me to believe that although a LOT of people write about and use these myriad methods, precious few actually truly understand the actual real world application or need of these methods. Emphasis on real world.
In my searches, I remembered I had a copy of the .Net 4 Design Patterns from http://www.dofactory.com. In that there is a reference application (Patterns in Practice) and deep within that is the answer (if not the actual implementation) to my question.
Light at the end of an unnecessarily long tunnel and all that.
Eventually, I’m hoping the next release of WCF Data Services, oData and Entity Framework will allow me to throw away just about everything and then just have client -> service -> domain; all in wonderfully simple code.