DetailViewModel with it's own serviceAgent example

Sep 9, 2011 at 11:06 PM

Hey Tony;

  I have a app where the viewmodel (vm) fires off a detailViewModel (dvm) (almost verbatim like your 3 step product example), but my detail view model requires more data from the domainService (collections for drop down list, etc.  Right now I'm loading the 'extra' info into my vm then setting my dvm collection equal to the vm collection (like you do with 'Categories', but as my app is growing, I'm starting to fire off various differnt dvm from the same vm, and each will need their own data. I think it'd be better if my dvm's get their own data via a serviceAgent, my concern is maintaining the context so that I can do my saves, rejects and removes from the main vm (like your app does).

Do you have an example that shows the vm launching a dvm that utilizes it's own serviceAgent and then passing itself back to the vm?  Or could you explain how you would do it? 

Maybe it's a too late on Friday, or I'm just not getting the 'best' way to do this or perhaps over/under thinking it.

Thanks for any help Tony (or anyone willing)

Robert

Sep 10, 2011 at 5:49 PM

Hi Robert

Just a quick thought from the top of my head on a Saturday, but how about changing the ctor of your dvms to accept your service agent and to pass that in when you fire them up?

Cheers - Graham

Sep 10, 2011 at 8:41 PM
Edited Sep 10, 2011 at 8:42 PM

Thanks for the response Graham...I'm not sure I explained my problem quite right (or maybe I don't fully understand your solution)..either way let's try this, what I hope is more clear question

 

Imagine (based on the 3 Part SimpleMvvm-Main example that comes with the toolkit) that each Category type item, has it's own detailViewModel  and specific logic, collections and view it needs for adding and creating a item in that category, which then comes back to the ProductListViewModel where it can be saved, removed, etc etc.

What would you do (keeping it based on the example)?

For services:

expand IProductListServiceAgent to encompass any calls needed for any of the details? or

Create ServiceAgents for each detail view model  (if so, how does that code work..use the locator?)

For the viewModel and detail viewModels:

load the detail view model specific collections in the viewmodel and load up detailviewmodel there? or

load the detail specific collections in the detailviewmodel?

 

I'm very new to the most all of this (MVVM, Ria Services), so bare with me, I appreciate any help....just suddenly my prototype project got very popular and I need to think i terms of adding 10 to 20 new 'Items' with very different detail view models for each, but centralizing back to 'ProductListView' where user choices will be made.  Exciting times, but I also don't want to code myself into a corner or overlook a DataContext or concurrent user issue that may be out of my scope of thought.

 

Thanks again

Robert

Sep 10, 2011 at 10:23 PM

Hello Robert,

I had the pleasure of working on a large, complex Silverlight project which incorporated parts of my Simple Mvvm Toolkit.  For large project, the principle of Separation of Concerns will help you achieve better modularity and maintainability over time.  For this reason, I prefer to have separate service agents for "summary" ViewModels (deriving from ViewModelBase) and for individual "detail" ViewModels (deriving from ViewModelDetailBase).  The ViewModelLocator exposes all ViewModels as properties (using the mvvmlocator code snippet).  This goes also for ViewModels, such as simple dialogs, that may not have a service agent (using the mvvmlocatornosa code snippet).  In SimpleMvvm terms, each View is responsible for getting its ViewModel from the locator by binding its DataContext to the property on the locator which exposes the ViewModel for that View.  The locator essentially creates the ViewModel on demand and supplies a service agent to the ctor of the ViewModel.  Hope this helps a bit.

Cheers,

Tony

Feb 27, 2012 at 8:32 PM

This sounds similar to what I'm currently struggling with...how 'thin' or 'thick' to make these service agents?  I get the impression from the tutorial that a service agent should be created to only service the viewmodel that is using it.  That would keep the serviceAgents small and compact...which is all fine.  But what happens when you realize you might want to make a call to get 'lookup' type information for combobox drop-down lists and you know the code to get those drop-down items already lives in another service agent?! 

Are the associations across V VM and SA like this?

View (1) -> (1) ViewModel (1) -> (1) ServiceAgent -> (n) ServiceAgents

Or this?

View (1) -> (1) ViewModel (1) -> (n) ServiceAgents

The whole combobox drop-down thing just has me stumped for some reason.

Regards,

Randy