Refactoring CSLA.NET NameValueList and Command Object Return Value

In my current project using CSLA.NET, one of the drawbacks that I noticed on the NameValueList and Command object implementation is the fact that it forces one return value type. Ideally, the best light weighted Name Value return is <key, String> but in our case we are required to have Multi-value object for different purposes.

The best example of NameValueList is it use to hold collection for drop down collections and grids. So for example, for the case of Users List some drop down list only need First Name and Last Name. However, sometimes we may need more fields. The return collection can be in different combination of the fields for different purposes.

Hence, forcing to one Return value type has the following problems that I noticed

1. People tend to create new NameValueList Class every time they face completely new return type even though the idea of NameValue class is similar; for the case of User, either <key, <LastName, FirstName>> or <Key, <FirstName, LastName, Age, Sex>>.
2. Or, add more properties to the existing return Value for the new return type they desire to have.

Elaborating the first problem, even though it is efficient, we might end up creating many similar classes just for the sake of different Return Type. Probably, we might name each NameValueList class with post fix of the return value.

In the second case, having one NameValueList and return value of all combination will have efficiency issue. If we have 20 variables in the return value but we are looking only two return value of collection for one specific case, we will end up initializing 18 return values of collections.

Probably the simplest approach is to have <abstract Class> as a return value instead of actual <Concrete Class> so that we can define as many Return Types inside the NameValue Class.

In my case, <UserNameValueList> will have an empty abstract class <INameValueListResult> as return type.

Inside the class, I have three return Types that implement <INameValueListResult>, namely <GetUserNameListResult>, <GetUseNameAndAgeResult> and <GetFullUserInformationResult>

Depending on the Criteria we use the different return types and consume. Probably, we can have as many return types as we create different Criteria classes. The consumer should know to what Return type it should cast the <INameValueListResult> value.

In my case, I have the following code that utilizes the return type at run time in my aspx page

============================================================