Which CSLA class to choose?

RichardETVS posted on Tuesday, March 27, 2007

I am a bit confused about the choice for some objects.

Let’s say I have the Folder class, who has a field _DocumentsCollection. This field will contain instances of Document class. The Document class has a field _WritingUnitsCollection.

This field will contain instances of WritingUnit class. The WritingUnit class is Composite Design pattern, with a leaf, BasicWritingUnit, and a collection of WritingUnits, WritingUnitComposite.

Here is the UML diagram.

I have to be able to retrieve and edit each object individually. If I retrieve a Folder instance, I have to treat all its documents and the writing units of each document. But I can have to retrieve a document directly, even to retrieve directly with a WritingUnit. If this Writing unit is a WritingUnitBasic, I’ll do basic operations with it, if it is a WritingUnitComposite, I’ll iterate through the collection of WritingUnits.

My confusion is about the choice of CSLA objects. Root, child, BusinessListBase, EditableRootListBase, or another? Thank for yours lights :) !

Cordially

Richard

Bayu replied on Wednesday, March 28, 2007

RichardETVS:

I have to be able to retrieve and edit each object individually. If I retrieve a Folder instance, I have to treat all its documents and the writing units of each document. But I can have to retrieve a document directly, even to retrieve directly with a WritingUnit. If this Writing unit is a WritingUnitBasic, I’ll do basic operations with it, if it is a WritingUnitComposite, I’ll iterate through the collection of WritingUnits.

You are facing two problems simultaneously:
- you are mixing up several use cases, at least so it seems:
    - retrieving a Folder w Documents w WritingUnits is one use case:
       - Folder = EditableRoot
       - Documents = EditableChildList
       - WritingUnits = EditableChildList
    - Retrieving a Document directly is another use case
       - Document = EditableRoot
          - WritingUnits = EditableChildList
    - and retrieving a WritingUnit directly is again another use case
       - WritingUnit = EditableRoot

If Folder and Document need to be editable in each of these use cases I think you may be in for a Switchable object (I am sure this comment will liven up this thread with people giving you warning about bad design, I hope to hear these folks as I am not sure myself ;-) ).

Otherwise, if only the WritingUnits are editable in every use case, you Folder and Document can be readonly objects and you could make WritingUnits a EditableRootList with WritingUnit be an EditableRoot. Then the Folder and Document are just different means to get a list of relevant WritingUnits, but you call save on the WritingUnits list.

So far about mixing up use cases.

The second thing you face is a flexible hierarchy (through the CompositeWritingUnit). Typically you would display these in treeviews, and as you probably already noted: treeviews don't support databinding (at least not yet in dotnet 2.0). So you will have bind items manually anyhow, so I would suggest to get all WritingUnits relevant to a Folder or Document in a list (EditableRootList/EditableChildList, depending on your use case design, see also my previous point). Each WritingUnit has properties that point to its parent and perhaps an index somehow so that you can figure out in the UI what the tree would have to look like. It is not too hard to catch all drag-drop events and reflect the structural changes in your BOs. I you don't need to support structural changes (drag-drops) than even better! ;-)

Just some food for thought.

Good luck!
Bayu

RichardETVS replied on Wednesday, March 28, 2007

Thanks for your reply, Bayu, it is helpful.

I think it is clearer for me, now. As I use db4o, I’ll not go for the true “use case” driven design, which needs a relational database to be efficient. But I ‘have a mix between data-centric and use-case design.

Actually, in my object model, the CSLA BO does not access to the data. The Data_PortalYXZ methods delegate the work to a data access layer who does the job with db4o. For that, this layer does not save the CSLA BO, but a persistence model, with simplified objects.

So, in the persistence layer, I can have Folders, Documents and WritingUnits (who are not CSLA descendant classes), and in the Business Layer, I shall chose how to implement them (EditableRoot, EditableChild, etc.) according to the use case.

Again, thanks :)

Richard