Ordered list with various class types

eulerthegrape posted on Tuesday, October 28, 2008

Obligatory: "forgive my newbie-ness"

Hi all,

I've been reading through a lot of threads and found pieces of answers but nothing that totally answers my issue. I have a root object with a collection of child objects. I want to assign objects of three different types (this could be more) to the root object's child collection and maintain the child order within the list.

The, incomplete, solution I have is as follows:

1. An interface called IMeasurementFunction that defines a name and id parameter
2. Three different child info objects that inherit IMeasurementFunction (MeasurementMeasurementInfo, MeasurementCommandInfo, and MeasurementSpecialCommandInfo)
3. A wrapper called MeasurementFunctionWrapper that takes an IMeasurementFunction and contains the order and holds the object type
4. The wrapper implements factory methods and data access
5. A MeasurementFunctions list that assigns a MeasurementFunctionWrapper to the list, maintains it's type (for special display pruposes), and manages the order.

Is this feasible? How would you rate this solution? Should I instead create and abstract class instead? Other ideas? As Linda Richman on Coffee Talk would say: "The industrial revolution was neither industrial nor a revolution. Discuss.' ;-)

-Euler

RockfordLhotka replied on Tuesday, October 28, 2008

BusinessListBase only requires that child objects implement Csla.Core.IEditableBusinessObject. And you get that for free if you subclass BusinessBase.

However, your interface must inherit from IEditableBusinessObject so you can use it as the type parameter for your collection.

public interface IMeasurementFunction : Csla.Core.IEditableBusinessObject
{
// your methods here
}

Then you can do:

[Serializable]
public class MeasurementList : BusinessListBase<IMeasurementFunction>
// ...

And that's that.

eulerthegrape replied on Wednesday, October 29, 2008

Awesome, Rocky himself.

Rocky, thanks for your help, this framework, and the book explaining it all. It's really helped in focusing my work.

However, because I'm not well enough versed, I'm face with a new problem, or two. If I inherit from IEditableBusinessObject, I now have to implement nearly 50 methods (I think I'm missing something here). Also, I think you were just using short hand for the implementation, right? The code would be as follows?

public class MeasurementList : BusinessListBase<MeasurementList, IMeasurementFunction>
{
}

Again thanks so much for the reply,

Euler

eulerthegrape replied on Wednesday, October 29, 2008

Ah, I think that's the kicker. They are ReadOnlyBase classes, because we weren't editing these objects in their separate lists just within the collective list and then really only editing the order parameter. That's why there's a wrapper class involved, which does inherit from BusinessBase. Should I change these to inherit from BusinessBase? This would eliminate the need to implement all IEditableBusinessObject's methods but then it feels like I'm straying from my use case.

ajj3085 replied on Wednesday, October 29, 2008

Well, if you need to have a list of readonly instances in an editable root object, it's prefectly acceptable to change them to BusinessBase subclasses. Just keep all of the instances properties as readonly (that is, don't implement property setters) and you should be good to go. This change doesn't have to affect your use case.

HTH
Andy

eulerthegrape replied on Wednesday, October 29, 2008

All this information is making things a lot clearer thank you all.

Yeah, I see the read-only-ness of this solution. It seems like there are always trade-offs. With the wrapper I was able to implement universal methods for fetching, inserting, etc. I now have to implement these methods in each child (or handle the specifics of child data access in the root object?). Perhaps having each child type implement data access is a good thing. Would I escape this drawback if I used an abstract class?

Thanks again for all the help Andy and Rocky,
Euler

eulerthegrape replied on Thursday, October 30, 2008

OK, I think I've painted myself into a corner.

I have a master ordered list to which items of the same interface can be assigned. Now I can assign, unassign, move up, move down. I created a master ordered list child to read in all the default children. All this works but I'm stuck with a list of various objects and no central way to save them.

Which of these two makes sense:
1. Cast children to master list child object and handle the saving here.
2. Conditional statement that directs to child's unique data access methods.

Thanks,
Euler

ajj3085 replied on Thursday, October 30, 2008

Can't you add a standard save method to your interface?

If you're using 3.5 or above, you should be able to get away with just implementing Child_Insert and Child_Update.. your collection need not do anything, and you can just call FieldManager.UpdateChildren in your root BO.

eulerthegrape replied on Thursday, October 30, 2008

Sure but without an implementation. And the implementation will be identical across all list items because they're all being saved to the same place. I guess I don't need a switch statement if I define an Insert, Update, and Delete method in the interface but now it feels like I'm duplicating behavior.

Unfortunately I'm stuck in the stone age with CSLA 3.0. But 3.5 sounds like it has some excellent updates. Maybe once I've finished this project I'll look into upgrading.

Thanks,
Euler

ajj3085 replied on Friday, October 31, 2008

What about a common base class, which has the duplicated behaviors (save, delete, etc)?

Also, 3.5+ won't help you as much as you think; you'd still have to put the Child_Insert in each class... so either way, it looks like your best bet is a common base class.. at which point, you might be able to lose the interface.