Aug 18, 2010 at 5:29 PM

You have some interesting code here, but I do have a few suggestions:

1) The ContextManager would be better with generic methods in addition to the non-generic methods.
2) Your UIDispatcher should return an IAsyncResult so that the caller can check if the action has been executed or dispatched.
3) Because any async call returning an IAsyncResult could possibly have executed synchronously, you should add operations to your _possiblyPendingOperations before executing them. That also means you will need put in exception handling to remove it again if the execute throws.
4) Consider exposing the EntityContainer from your service class instead of individual IEnumerable properties. The EntityContainer is designed to be used separate from the DomainContext. In your HelpdeskDesignData you can create your own instance of the EntityContainer without the DomainContext and fill it with display data instead of having to create IEnumerables for everything.
5) For your "static" list properties, consider using a PagedCollectionView instead of having to track if the data has changed yourself.

Aug 18, 2010 at 7:21 PM


This is great feedback.  Thank you so much for these suggestions.  Thie definately provides some great ideas for improvement.  I have a couple questions that you might be able to answer for me:

Regarding the PagedCollectionView - wouldn't this create a reference to a specific entity set, instead of Just creating a list of entities?  Perhaps my understanding of PagedCollectionView is a little unclear?  Also, would you recommend PagedCollectionView over the CollectionViewSource that I have been using?  Other than Paging, what other differences are there? 

The reason I used IEnumerable's for statics, was based upon speed that I found when binding a large list (for example 500 users) to a combo box.  CollectionViewSource seemed to cause significant slowness over a basic IEnumerable, and since I really considered the static collections to be read-only and I do not expect updates to be occuring from the application itself (although I did make it possible if some ViewModel decides to refresh the static entity type, it would trigger the update.  Based upon this, would you still recommend PagedCollectionView instead of the IEnumerable for static lists?  Might PagedCollectionView behave differently from the CollectionViewSource?

Thanks again,


Aug 18, 2010 at 8:30 PM

CollectionViewSource isn't an ICollectionView. It is a XAML interface to an ICollectionView. AFAIK, PagedCollectionView is the only public ICollectionView implementation available to us in Silverlight.

Yes, the PagedCollectionView would be a filtered, sorted, and current view of the underlying EntitySet. I try to arrange things so that the EntityContainer is the only place where permament connections to entities are kept. If an entity is deleted or detached from the EntityContainer then I don't want that entity to be a zombie somewhere else in my application. Obviously the ViewModel sometimes needs direct references for things like CurrentSelection properties and there may be business logic that holds onto lists of entities during a particular business process, etc. but I don't want my View doing that.

Your properties are checking themselves against the context and resetting themselves as needed so that is fine.

Aug 29, 2010 at 7:40 PM


Thank you for your tips.  I spent some time this weekend updating the toolkit, and building out a sample application further which demonstrates all the functions in the toolkit.  Your tips on using the EntitySet in the design-data actually worked out really well.  Also, I must thank you for the clarification on CollectionViewSource versus PagedCollectionView.  I wonder if you might have any other feedback for me regarding this toolkit?

Thanks again!