Object Design ... Help!

FireGarden posted on Saturday, August 26, 2006

I am trying to come up with a simple interface to allow a user to edit a listing of Accounts and assign them into AccountGroups.

The list of AccountGroups does not change. Accounts can be added to the system at any time at which point they must be assigned to an AccountGroup

So this is a very simple requirement but I am having problems with a Csla design. The approaches I have come up with so far are as follows:

Create a AccountGroups collection that has AccountGroup children which has Accounts collections allowing you to edit Account objects but I think that uses too many objects?

The other route would be to create a read only AccountGroupList to allow group selection and an Editable Root Accounts Collection with Account objects that would have its "GroupID" property updated when its assigned to a group.

I am just feeling so lost on how to do this and its a very straight forward thing to do. The end product would be a a TreeView of AccountGroups with Account children and the ability to drag account children into any AccountGroup then save. Also how do I update the treeview when an account moves into a different group?

Any suggestions are appreciated.

Regards,

Rob Wheeldon

P.S. I think this is an excellent support forum to date. Thank you community!

 

dean replied on Saturday, August 26, 2006

Rob,

Early on with CSLA I would get myself in these quandries. After enough repetitions from our fellow programmers here I learned to move back from the UI for a minute and look at the use cases for the business objects. You really only have an account collection containing account objects. The account object has a groupid field. This is the business object view of things.

Now the complexity is coming from you wanting to create a cool interface for manipulating these groupid's. But that shouldn't effect your business layer. You may want in the UI to create some new objects that manipulate your bus objects to aid you in creating the interface. But that is in the UI stuff and just uses the business objects.

Does that help?

Dean

FireGarden replied on Saturday, August 26, 2006

Thanks Dean,

   This does help. Given that an account is "in" an account group I had it in my head that this should be a parent - child BO relationship but I understand the perspective that I am only editing the GroupID property of the account.

Now the only question remaining is if I should use a root collection of accounts or a single root account object. I think for now I am going to use a root collection of accounts because I can bind that to a tree node and have changes reflected that way.

Regards,

Rob