Switchable, EditableRootList or other?

Switchable, EditableRootList or other?

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


Nicholas Trevatt posted on Saturday, July 21, 2007

Hi,  

Firstly, sorry for this simple design question and I appreciate any advice to help keep me on track.  I'm not sure if my problem lies in my UI or BO design.

I am creating a sytem where my teaching business needs to manage tasks/reminders per student such as Ring Student, or Book Exam etc.  I have implemented this as follows:

- Student (EditableRoot)
  - Tasks (EditableChildCollection)
    - Task (EditableChild)

In the UI I have a read-only TasksDataGridView on the students details screen and when double clicked I show a TaskDetailDialog form which accepts a new or existing Task BO for the user to update.  This works fine.However, now I'm creating an editable global filterable view of all tasks for all students and started implementing it as follows:

- TaskList (ReadOnlyCollection)
  - TaskInfo (ReadonlyChild)  

I'm also displaying this in a read-only grid and my intention was when double clicked to get the editable child task and show it in the same already existing TaskDetailDialog.  I quickly realized that I can't just *get* a specific editable child from thin air and that my approach won't work!  So, I am searching for the best way to edit my Task from the global view. I can see perhaps two options.

1) Make the Task BO switchable
2) Dump the TaskList/TaskInfo in favour of an EditableRootListBase/EditableRoot solution as detailed in the CSLA 2.1 Handbook.

I favoured option one to start with simply so I could reuse the already existing TaskDetailDialog form to update the task.  But after some reading (particularly the don't use a switchable objects statements) I think I'm off track.  Which option, or perhaps another one will help solve my little problem?

Cheers,
Nicholas







triplea replied on Sunday, July 22, 2007

I guess option 2 will suffice. The thing is that TaskInfo/TaskList have their own behaviour, responsibility and criteria so you'd probably need to convert TaskInfo/TaskList to EditableRootListBase/EditableRoot objects. Since they are quite similar to your Tasks/Task object, you could have a "TaskBase" object and share some methods, in order ot avoid writing duplicate code. Kind of what the Assignment class does in PTracker.

JoeFallon1 replied on Sunday, July 22, 2007

I sometimes use a top level root BO that just contains a child. (Or many other BOs.) This root BO is a Use Case Controller object. It coordinates the data for the use case. In your example it allows you to fetch the single child BO after going through the dataportal of the root using the childID.

Joe

 

Nicholas Trevatt replied on Sunday, July 22, 2007

Hi Joe,

That sounds like a definite possibility.  So to clarify what your suggesting for my scenario...I could create a TaskController(EditableRoot) which is able to fetch task data and pass it onto the Task(EditableChild) which is a child of TaskController?

Thanks,
Nicholas

JoeFallon1 replied on Sunday, July 22, 2007

Yes.

As a root object it can have its own validation rules and data portal calls.

You may not need that extra stuff in this case but the idea still holds true.

Or you may have extra rules for this use case which don't exactly fit your child BO - you can now add them to your TaskController root BO.

Either way your UI fetches a TaskController BO and it in turn fetches the specific child based on input criteria like TaskID. The you can save your root BO which saves your child BO in the normal fashion. In the root, be sure to Override IsValid and IsDirty to include your child BO.

Joe

 

 

 

 

Copyright (c) Marimer LLC