How Can I implement different type of collections for the same object?

dotnetbrix posted on Thursday, March 01, 2007

Hi guys,
Read the book ,thought I understood it but obviously didnt.

Scenario:
Ability to fetch the customer object or a collection of customers in both readOnly and Editable mode

In some part of the system both the object and the collections are readOnly and in some part of the system are fully editable.
Also in some parts of the system I would need a NameValueList in some other I would use a different collection for performance reasons.
This are hypotetical scenarios but very very common.

How do I build in this flexbility?

Do I create a class for each of them?

like:
Customer (fully Editable Object)
CustomerListInfo(ReadOnly Object)
CustomerListReadOnly (ReadOnly)
CustomerList(fully Editable)

    [Serializable]  //Full Editable Object
    public class Customer : BusinessBase<Customer>
    {
    }

    [Serializable] //ReadOnly Version
    public class CustomerListReadOnly : ReadOnlyListBase<CustomerList, CustomerListInfo>
    {
    }

    [Serializable]  //ReadOnly
    public class CustomerListInfo : ReadOnlyBase<CustomerListInfo>
    {
    }

    [Serializable  //Full Editable Customer List Object
    public class CustomerList: BusinessListBase<CustomerList, Customer>
    {
    }

IS THIS THE WAY? or Am i missing something?Obviosly is not possible to have an overload of the Fetch Method is it?
Also important is the Criteria class ,Is this used as filter?
Are there somewhere some more complex example that I can dowload to understand how to use it more complex scenarios?

Looking at the forum and on the net it looks like there are a lot of CSLA users out there.

From a CLSA Beginner point of view it would be nice if people could upload small apps/tutorials they have done.
Nothing wrong with the project tracker app ,but sometimes a different example does the trick and all becomes clear.

Is somebody willing to send me a small app/example they have done during their learning process?

thanks a lot
dotnet@devnet247.com

hurcane replied on Thursday, March 01, 2007

Rocky always advises designing your objects on behavior rather than data. The use case that needs an editable customer should have an editable customer object. the use case for a read-only customer should have an object for that case, which would not be an editable customer.

Most of us start out wanting to model data because that is our comfort zone. You may want to here a customer info object with lots of properties. This works well when showing properties for a single customer, such as an Enter Order use case.

You may try to use the same object for a customer lookup use case, but performance is terrible. Then you make a more focused customer info object for that use case.

The goal is not reuse of database code.

dotnetbrix replied on Thursday, March 01, 2007

Thank you for your reply.I thought that was the case that is why i posted the small examples.I agree.

I just needed confirmation .

Are there any examples somewhere to download apart from projectTracker ?