Case for a switchable object?

cmay posted on Tuesday, May 23, 2006

I am trying to mock up some examples using CSLA.Net

In the book, it states that if you believe your object should be a parent AND a child, then you probably have a flawed design.

Well the hierarchy I was trying to replicate is this:

Invoices ( collection )

Invoice

DetailItems ( collection )

DetailItem

In this, I believe "Invoice" is both a child and a parent.

Is this not a case for using a switchable object?

I am new to CLSA, so if I am off please set me straight.

xal replied on Tuesday, May 23, 2006

Well, in general, if you're viewing your list of invoices, then you probably don't need the detail items. And if the user decides he does want to see the invoice's details, then, you provide a way of accesing an invoice object with all the needed details...

So, you could have a readonly collection for Invoices with readonly Invoice Items that contain a brief summary of the invoice (the data the user will usually want in a list).

And you would have an invoice editable root object that contains all the details of the invoice (like a collection of detailitems).

Andrés

guyroch replied on Tuesday, May 23, 2006

Here is a simple match to you example.

Invoices -> BusinessListBase (This is your Root object, the only one not calling MarkAsChild())

Invoice -> BusinessBase -> MarkAsChild()

DetailItems -> BusinessListBase-> MarkAsChild()

DetailItem -> BusinessBase -> MarkAsChild()

Hope this helps

cmay replied on Wednesday, May 24, 2006

But if someone were editing a list of invoices and you wanted to provide the functionality that they could undo their changes or commit them all, then wouldn't you have to use 1 object graph?

For example, if you showed a list of invoices and some were to be deleted, some new ones would be added, some would be edited, and some would have their detail items modified, wouldn't that be a case for creating a structure like I mentioned?

xal replied on Wednesday, May 24, 2006

Well, if that is your requirement, then that is your requirement....
But seriously... Who wants to edit 10 invoices at a time and save all or none??

What I generally do is have the readonly list, and allow them to load full blown objects for editing and adding which open in another form / tab. These have their own "save" button. Deleting doesn't need a new form so, that's about it.
Once an item has been added / removed / deleted I refresh the readonly list. You can refetch it. Personally, I use Active Objects and the observer lets you do this really easily without doing another trip to the db...

Anyway, for the cases you do need the editable root collection:
As a side note, I always try to avoid grand children and I've always found a suitable solution to the problem that doesn't involve a deep object graph. But if for some reason I create them I lazy load the grand children.
The reason for this is that loading grand children is complex and takes a lot of time and usually the user will edit just a minor portion of the whole list.

I hope it helps.

Andrés

DansDreams replied on Wednesday, May 24, 2006

xal:
Well, if that is your requirement, then that is your requirement....
But seriously... Who wants to edit 10 invoices at a time and save all or none??

It's not really that hard for me to imagine a scenario...

Well, let's replace invoices with orders for what pops first into my mind. I can see a form where you want to list a particular customer's open orders and allow something like rearranging their delivery dates to manipulate the effects on the customer's credit aging. The read-only list won't do the trick, but you don't really need to load the grandchildren.

The standard response for this kind of thing has been that you'd need several invoice objects, but that seems to get messy right quick and create a recipe for disaster. This kind of thing is why I've suggested in the past that the best solution is a true OO one wherein there would be two invoice objects but the main all-capable root version would contain the other via aggregation/composition. This seems to me to be the only way in the long run to keep from duplicating business logic all over yet still having the good division of functionality.

mtagliaf replied on Wednesday, May 24, 2006

I agree with xal on this one.

For the "delivery date rearranger" - that sounds like a new, special purpose collection to me - one where only the delivery date is read/write and other fields are readonly.

By having it as its own object, you can impart different security restrictions on it. For example, a customer service rep may not have the ability to create new orders, but is allowed to rearrange delivery dates in the way you describe.

matt tag

xal replied on Wednesday, May 24, 2006

Perhaps I wasn't clear in that comment, but what I mean with that question was establishing that you probably don't want _invoices_ which are separate entities and that by definition they should contain line items and live in an isolated transaction of their own.

Yes, I have several cases where I have editable root collections, but in those cases I don't have grand children, and by definition, an invoice will have children (which would be grand children if the invoice is inside a collection).

About the customer's orders... yes, you have a a collection of order items for customer x, but I don't really see how those items could have grand children...
In this scenario, I'd have a read only list of customers with "open orders" and then I'd allow them to open a customer order with all the items they ordered.

Again, it all comes down to what your requirements / use cases demand. But from what I've seen -so far- the more complex the case/hierarchy the more likely it is that the user will not like it or not use it or ask you to change it.
If you're editing 10 invoices at a time, and they're not persisted, and you have an electrical failure, you loose 10 invoices. Yes, this is an extreme case, but this sort of thing happens. ("*** happens" as some would say)

It's not the same to have to recreate an order of ten items than recreating 10 invoices with all their items. So, all I'm saying is that you need to reaaaally think hard to avoid getting in a position where something will be difficult to create, difficult to maintain and difficult for other to learn / use.

Andrés