Ordered list with various class types

Ordered list with various class types

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

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.' ;-)


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:

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,


ajj3085 replied on Wednesday, October 29, 2008

Aren't your other classes, which implement your interface, inheriting from BusinessBase?

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.


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,

ajj3085 replied on Wednesday, October 29, 2008

I don't see a problem with the child objects inserting or deleting their related row in the database.  That's typically how I handle things.

eulerthegrape replied on Wednesday, October 29, 2008

It's how I typically handle things two but I thought I got around having to write a lot of similar code for each child of the same interface.  Maybe I should invest in codesmith...

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.


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.


eulerthegrape replied on Thursday, October 30, 2008

And as far as I know I can't scope these methods "internal" but I'm not sure what I lose in this.

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.

Copyright (c) Marimer LLC