Reputation: 171
I have another question here with the Unit of Work (UoW) and Repository pattern. So I like the repositories with UoW that the TempHire solution shows, very nice and I understand that. However, when you pass in a query that requests for an entity to be .expand
or .select
off of a parent, does the EFContextProvider call the repository for that action, or does it go straight to the Context
. I looked into this a little, and I see that the EFContextProvider
has it's own instance of the context.. This worries me because I have abstracted some things out using the repository pattern, however I don't think they are applied when doing these nested actions. Can anyone confirm this for me? If this is correct, Is there anyway to set this up so that is will go to my repository, which mimics the DbContext
, for these nested calls?
Thanks Guys and Gals. Keep it Breezey
Upvotes: 0
Views: 169
Reputation: 211
The repositories as implemented in TempHire return the base IQueryable for any query. An .expand or .select gets simply appended to the base IQueryable before the query is executed. The EFContextProvider never calls the repository. The WebAPI controller calls on the repository to get the base IQueryable, which the repository gets from the DbContext inside of the EFContextProvider. The repository can further append to the IQueryable and so can the WebApi controller before the final IQueryable is returned to Breeze.NET which executes it. In other words all the logic you have in the repository that returns your base IQueryable will apply whether you execute the query as is or do an .expand or .select on it.
Upvotes: 1
Reputation: 371
EFContextProvider provides two things for breeze.js - metadata and SaveChanges. Queries go to the UoW repositories (please look at https://github.com/IdeaBlade/Breeze/blob/master/Samples/TempHire/TempHire/Controllers/ResourceMgtController.cs).
Upvotes: 0