BO listening to another BO's Saved event?

BO listening to another BO's Saved event?

Old forum URL:

ajj3085 posted on Monday, November 10, 2008


Does anyone see any problems with a BO listening to the Saved event from another BO?  I'm talking about two root objects which are editable.

This is the scenario:
A part can be edited, but to adjust inventory another BO is needed.  (Changes are recorded as new rows, which are summed back to the original record at the end of the month).  To do this, the Part BO creates an instance of the adjuster BO which is edited in a second screen.  When the adjuster is saved, the original part BO needs to update it's quantity property (which is read only for the user); how it does this I'm not concerned about at this point.

I'm specifically thinking about the Part BO being serialized when the adjuster is saved, or memory leaks because the event handler is listening to the "old" adjuster BO.


rsbaker0 replied on Tuesday, November 11, 2008

I have a very similar use case and was unsure exactly how to handle it.

What I did was to actually make the Adjust BO an optional "child" object of the Part BO to handle the case where both are being edited at the same time.

When the Part BO saves itself, it looks to see if it has an Adjust BO. If so, it saves the Adjust BO and then changes its own quantity property.

An Adjust BO can be used by itself also, in which case the corresponding Part BO will pick up the quantity change the next time it is read from the database.

ajj3085 replied on Tuesday, November 11, 2008

Thanks for the feedback.

My use case is a bit different; it's entirely possible that a user has permissions to be able to adjust the inventory but not ever edit the actual part itself.

I think I figured out how to do this.. by not doing it. 

Instead, the two BOs are separated, and I added a RefershInventory method to the part BO.  This can be called via a timer or after the Adjust Inventory window closes.  I'm not sure it's the part BO's job to make sure it always has the correct value, but providing a way to refersh that value seems like an acceptable responsiblity. 

This way I don't need to worry about event handlers and memory leaks, and the Refersh method I created to be thread safe. 

rsbaker0 replied on Tuesday, November 11, 2008

Interesting, because I have the same possible permissions limitation and hadn't stumbled over that yet.

I oversimplified my description above -- what the Part BO would do was actually refresh itself from the database, much like what you are doing.

As an aside, this general class of problem was, by far, the most difficult legacy use case we had to shoe-horn into the CSLA editing model. We also write out a transaction record of the inventory adjustment, and the user might even have selected a "reason code" or comment to go with the transaction. The adjustment might have also required adjustment to other records (e.g. decrement available quantity for a lot number, "burn" quantity when consignment inventory was involved, etc.

Since all of this had to occur in the same database transaction as the actually quantity adjustment, a switchable child Adjust BO seemed like one way to make it work.

The legacy application would (Gasp!!) actually hold the database transaction open while a confirmation prompt for the reason code, comment, etc. for the quantity change was sitting there in front of the user.

ajj3085 replied on Tuesday, November 11, 2008

Wow, I'm really glad I posted this, because what you've done sounds very similar to what I'm doing, including writing a separate adjustment record to the database complete with reason!

That legacy application just sounded like a bad hack.. I bet they were happy to be rid of it.

I'll be sure to post more questions like these as they come up.. and hope you notice them!


Copyright (c) Marimer LLC