Should BusinessListBase & ReadOnlyListBase support managed properties?

Should BusinessListBase & ReadOnlyListBase support managed properties?

Old forum URL: forums.lhotka.net/forums/t/6887.aspx


Cuong posted on Friday, May 01, 2009

Hi,

In my applications I always have to store the criteria object (that was used to fetch the list) inside the list. The purpose is to display or to print the list, the criteria will be used as the list's extra info (e.g report's title).

For example:

[Serializable]
public class MyList : ReadOnlyListBase<MyList, MyChild>
{
    public MyCriteria Criteria { get; private set; }

    private void DataPortal_Fetch(MyCriteria criteria)
    {
        this.Criteria = criteria;
        // Fetch here
    }
}

This code works fine for WindowsForm app. But in Silverlight app, unfortunately both BusinessListBase & ReadOnlyListBase do not support managed properties so I have to implement tedious OnGetChildren/OnSetChildren methods for each list. I think it will be more usefull if BusinessListBase & ReadOnlyListBase could support managed properties like their children BusinessBase & ReadOnlyBase.





JoeFallon1 replied on Friday, May 01, 2009

I rarely store the Criteria class inside a BO anymore. I moved them to their own namespace in my app years ago. When you inherit from CriteriaBase you tell it the Type of BO to create. By centralizing my Criteria objects this way I can re-use them in various BOs. In fact I had a "SingleCriteria" object years before Rocky introduced it in CSLA. (I just was smart enough to make it generic!)

Joe

RockfordLhotka replied on Friday, May 01, 2009

There are two reasons the design is the way it is.

  1. Data binding doesn't support the idea of properties on a list object - it binds to the items the list contains. So having support for properties on a list object would be typically not useful in that regard, and would lead people to think it was a good idea (and then we'd have whole other threads about why you can't actually use those properties through data binding)
  2. Most lists are focused on the child objects. Things like the field manager do incur some overhead in the serialized byte stream. It seems like a poor choice (to me) to inflate the size of all lists on the off chance that some lists have a few property values on the list itself.

As always, I'm open to discussion on alternatives that would enable your scenario without having a negative impact on these other issues.

Copyright (c) Marimer LLC