I have setup a repository to query a table and return a subset based on a parameter that comes from the current selection of the parent datagrid.  i.e. when I select a manufacturer I want to populate related links and addresses in a child grid.

 

I cannot for the life of me figure out how to pass in the current manufacturer ID.

 

This is what I have in the repository, where do I add an argument so it can be passed in, and how does it get passed?  right now it just loads the data for the first manufacturer and I have no idea how to get it to update, or to pass the currentid.

Why doesn't your "LoadManufacturersLinks" method take a Manufacturer ID parameter. I must be missing something.

I am happy to give up on repositories unless someone can produce one clear example of how a devforce repository should look in the MVVM light world and how the viewmodel needs to interact with it.  All this abstraction is giving me a headache.

 

I have been using the way you organized the repository in your mvvm light example, which defines the interface, then each class for production and design, and finally the entiryqueryoperation for each.

 

 

 

It is important to avoid blindly following any one example shown in demo code ... any demo code. There is no one way. And the author is not trying to account for every circumstance and often cuts corners in one area while concentrating on another.

 

I would say that the Repository in MVVM Lite1 is only one example and, as it happens, not typical of the way I would write one today (which may be different from the way I'll write it tomorrow). You must look to these demos for inspiration ... not prescription.

 

MVVM Lite is almost the simplest MVVM Light example we could write. The next step in the learning progression might be BookShelfDF; see http://links.ideablade.com/drc-bookshelf - http://links.ideablade.com/drc-bookshelf

 

BookShelf has a repository that better refects current thinking. You will notice that query methods return void rather than operation coordination objects (e.g, EntityQueryOperation<T>); I now recommend against returning the operation object. 

 

The query signature now sports both success and fail callbacks as final parameters. The signarture doesn't include a collection to receive the results; it expects you to do what you will with the results returned to the success callback. I'm not against a collection parameter for everyone; I personally find it troublesome because, as a repository author, I don't know if I should clear the list first, create it, fill it, filter it further, turn off events while I'm filling, etc. etc.  Better to leave those decisions to the caller (typically a VM). But you are welcome to think differently about all these points.

 

MVVM Lite didn't have any parameterized queryies. You don't write a query method that you don't need.

 

BookShelf DOES have parameterized queryies; see GetBooksByCategory. In my earlier reply I showed you an example that was similar in this respect. Did you have trouble with that? You didn't say in your subsequent posts.

 

BookShelf is also a richer exploration of an application that combines design-time and runtime modalities. The accompanying document walks you through how that works and the tour video will provide clues too.

 

Hope this helps.

 

Retained the design repository for simplicity of this example. We recommend that you only have one version of a repository and switch between production, design, test, and development environments by swapping the EntityManager that is provided in the constructor parameter as we do in BookShelfDF; see http://links.ideablade.com/drc-bookshelf - http://links.ideablade.com/drc-bookshelf