The first solution that comes to mind is a Command object that locks the inventory. After a successful Save(), you fire off this command. Or, you could fire it off in the DP_ methods of your base order object. Unless locking inventory is part of a use case/user interaction, I wouldn't create a full-fledged BO to do the locking.
HTH
- Scott
I'd still make it a separate Command object. Given these conditions, I'd probably launch the command from the DP_ methods inside your root order object. That way, you can share the transaction that's been set up. And you could pass the order object to your command (via criteria) to let the command determine whether it needs to do anything. That would be the least intrusion into your order codebase. But you could certainly make a case for putting the determination of locking inventory into your order object, and then you don't have to pass it to your inventory command. I guess it depends on how you view the responsibility - it's a bit of a toss-up for me.
- Scott
Why not implement a workflow that is triggered when your order is saved? Then you can customize what does and doesn't occur as part of the workflow, giving you greater flexibility into the future.
Your workflow activity can make use of a command object as suggested. So, your business logic would trigger the workflow in response to your order being saved, one of the workflow activities would be "LockInventoryActivity" that implements a command object to perform the task in the data store.
This approach will allow you to change the business PROCESS (as opposed to logic) as needed.
P.S. Workflow activities are reusable, so you can add a workflow to your quote and reuse the same activity to lock the inventory!
Copyright (c) Marimer LLC