Serialising filtered list on ReadOnlyCollection (Silverlight)

Serialising filtered list on ReadOnlyCollection (Silverlight)

Old forum URL:

Charleh posted on Friday, February 18, 2011

Hi all,

I am currently working on a Silverlight app within which I have a BO which has a read only collection as a child property - this object is not actually a 'child' as such and is simply a lookup list loaded in during the data portal operations. I filter this list occasionally when a certain property on the parent changes

The filter is stored on the object under an ObservableCollection and is repopulated when the filter method is called - this means I can always bind to the collection itself, or bind to the filtered list on the collection.

My problem is that when I load a BO, the business rules fire on the server side to set the object up - during this the filter method fires and creates a filtered view of the lookup - when the object is serialised and ends up on the client side the filtered list is null. The filtered list is not being serialised

I'm assuming you can't have managed props on a readonlycollection (only the readonlyobject?), is there any way to ensure this list is included in the serialisation process? What are the criteria CSLA uses to decide what gets included in the serialisation process?

If not, what's the best method of ensuring that the business rule that creates the list is fired on the client side when the object is deserialised?


Charleh replied on Friday, February 18, 2011

I think the alternative is to create a filtered version of the read only list on the parent object and bind to that instead - at least then the values will get serialised

From one of Rocky's posts it seems to suggest that only managed fields and child lists get serialised by IMobileObject

RockfordLhotka replied on Friday, February 18, 2011

You probably should not view this read-only object as a child of the editable object. What you have sounds more like a using relationship than a containment relationship.

You can use a unit of work object to retrieve both the editable root and read-only root at the same time, and that's usually a better solution. I discuss the UOW pattern in the Using CSLA 4: Creating Business Objects ebook, and there's some info in the FAQ too.

Charleh replied on Saturday, February 19, 2011

Hi Rocky,

That makes sense - I could encapsulate these objects in work layer using UOW

I did intend to move a lot of the business properties to a viewmodel implementation as most of these properties are used exclusively by a particular view, but I think that some other views may also want to see this data at some point when extending the app.


Copyright (c) Marimer LLC