Setting a view model entails many service layer call is this correct?
My architecture is thus: UI project (MVC), connect开发者_C百科ed to my Domain Service Layer (Business rules etc), connected to a Repo Layer.
When setting up view models i seem to be making many calls to the database 9via service layer) to set up a viewmodel (i.e. view) within the controller, is this the correct thing to do...
E.g. I have a client, they can become a Head Office (checkbox), if they become/ or are a HeadOffice they have the option to add many different clients. This particular view will contain: The client details, Available clients to add and current clients that are part of the head office...
To me it appears as if I should be checking everying within the Domain Service Layer and giving back to the controller what it can see i.e. If it is a HeadOffice is has x number of clients it can add???
I'm not entirely sure on the question, but here is my understanding of the issue...
1) A client record will contain certain information in all cases, and you can get back a client record in one call
2) IF a client record has IsHeadOffice == true, you might additionally choose to load an IEnumerable list of client records that "belong" to the "head office client"
I don't really see a problem in making two calls, one to the "get client" method and one to the "get clients for head office user" method.
You could façade these in your service layer and return the entire client, with all associated clients in one call if you wish.
If you try and tie your service up with your UI, you will write unnecessarily complicated methods to return "complete" sets of data. If you are calling 50 different methods from the UI, that might not be performant and you might want to aggregate it further down the stack.
精彩评论