John,

Albeit "innocent," it's a good question. It really boils down to when you'd want to use an event object.

We use event objects to coordinate business logic among multiple classes and to prevent classes from knowing too much about other classes. For example, we have a "CancelOrderEvent" in our project that coordinates functionality contained in several BizObj classes.

When we want to cancel an order we call OrderBizObj.CancelOrder(). All this method "knows" is that there is a particular event that handles the coordination. (In fact, we have a factory to further abstract the event object generation, because some of our clients have special functionality and we may need to instantiate a subclass of the event)

Now, when we have a business reason to change what happens when an order is canceled (maybe cancel A/R... maybe deactivate the customer), the event is the only object that needs to be aware of the number/name of classes/methods involved. This type of maintenance is easier since it's more logical to change the CancelOrderEvent than the OrderBizObj or another arbitrary BizObj choice.

However, if the only business logic being fired on the form is saving data that's already been changed by a user, then I would say an event object is probably overkill.

Hope that helps,
---J

>Hi,
>Thank you.
>Sorry for my innocent question.
>
>As I see, desktop application is mostly more interactive. Meant that, record/data will be stored in view and "appear" to user immediately. For example place order, cashier start new order, add lineitems, end order and make payment. All of these happen seperately, and save button will auto call form.saverecord() to save corresponding view. All relevant Business object will be triggered at that time.
>
>So, how can placeorder event object could work more "useful"? I still can't get the "real benefit" of event object in form.
>
>Thank you in advanced