Using a delegate

25 Jan 2006 7:42 PM

Jon

I am a little problem deciding when to use delegates and when not to. Is the
following a good example?

I have an order class and a messenger class (this does things like send
emails, pages, faxes). Currently we create the order and in the creation
function, we call other functions in sequence that do things that are not
order specific (other things may send emails besides the order being
created). Would it be better to create a delegate for the order creation
"event" and have the messenger class subscribe to it so it knows to send off
an email without the create function directly calling it? What's the real
benefit of doing that?

Example, an order is created like below...
***FormOrder
Private Sub CreateButton_Click()
Dim o as Order
o = new order (var,var,var)
End Sub
***FormOrder

Class Order
Function Create (foo,bar,boo) as String
    insert some stuff into DB
    'If needed, send an email
    Messenger.CreateEmail (OrderNum, Time, etc)
    Me.InsertCreatedLog(OrderNum, Time, etc)

    Return OrderNum
End Function
End Class

Class Messenger
    Public Shared Function CreateEmail ()
        'Insert records into DB for the email processor to pick up
    End Function
End Class

If using a delegate is the preferred way to go, can someone direct me to
some non-cryptic info on how to create the delegate and subscribe to/use it?

Thanks much

25 Jan 2006 8:02 PM

TrtnJohn

Using delegates/ events are a way to make an object independent of other
objects in the system. You should use them to report user intiated or
intermmediate events. In your case there really is no reason to wait for the
Create to complete and then fire an event. Instead, just let the create
return back and then pass the new Order to your Email object. I wouldn't
email right from the Create either as this is starting to break the
encapsulation of your Order object. Emailing an order is something that
should be performed by an Email object instead.

Show quoteHide quote

"Jon" wrote:

> I am a little problem deciding when to use delegates and when not to. Is the
> following a good example?
>
> I have an order class and a messenger class (this does things like send
> emails, pages, faxes). Currently we create the order and in the creation
> function, we call other functions in sequence that do things that are not
> order specific (other things may send emails besides the order being
> created). Would it be better to create a delegate for the order creation
> "event" and have the messenger class subscribe to it so it knows to send off
> an email without the create function directly calling it? What's the real
> benefit of doing that?
>
> Example, an order is created like below...
> ***FormOrder
> Private Sub CreateButton_Click()
> Dim o as Order
> o = new order (var,var,var)
> End Sub
> ***FormOrder
>
>
> Class Order
> Function Create (foo,bar,boo) as String
>     insert some stuff into DB
>     'If needed, send an email
>     Messenger.CreateEmail (OrderNum, Time, etc)
>     Me.InsertCreatedLog(OrderNum, Time, etc)
>
>     Return OrderNum
> End Function
> End Class
>
> Class Messenger
>     Public Shared Function CreateEmail ()
>         'Insert records into DB for the email processor to pick up
>     End Function
> End Class
>
>
> If using a delegate is the preferred way to go, can someone direct me to
> some non-cryptic info on how to create the delegate and subscribe to/use it?
>
> Thanks much
>
>
>

25 Jan 2006 8:07 PM

Jon

Thanks. If I wait for the create to return back, then I'm calling the create
email function from the button click event, right? Is that correct practice?
Shouldn't I be calling the create email from the business logic layer?
Sometimes this gets a bit confusing!

Show quoteHide quote

"TrtnJohn" <TrtnJ***@discussions.microsoft.com> wrote in message
news:28AFED43-897F-4C3C-BE28-C6596594C277@microsoft.com...
> Using delegates/ events are a way to make an object independent of other
> objects in the system. You should use them to report user intiated or
> intermmediate events. In your case there really is no reason to wait for
> the
> Create to complete and then fire an event. Instead, just let the create
> return back and then pass the new Order to your Email object. I wouldn't
> email right from the Create either as this is starting to break the
> encapsulation of your Order object. Emailing an order is something that
> should be performed by an Email object instead.
>

25 Jan 2006 10:27 PM

TrtnJohn

Yes. The form click would send the mail using YOUR Email object. (A business
object). I just view creating the order and emailing it as access to 2
seperate business objects. If you add too much functionality to your Order
object it starts to become too dependent and coupled to a fixed set of
functionality. This will make the object overly complex and not very
re-useable.

Show quoteHide quote

"Jon" wrote:

> Thanks. If I wait for the create to return back, then I'm calling the create
> email function from the button click event, right? Is that correct practice?
> Shouldn't I be calling the create email from the business logic layer?
> Sometimes this gets a bit confusing!
>
>
> "TrtnJohn" <TrtnJ***@discussions.microsoft.com> wrote in message
> news:28AFED43-897F-4C3C-BE28-C6596594C277@microsoft.com...
> > Using delegates/ events are a way to make an object independent of other
> > objects in the system. You should use them to report user intiated or
> > intermmediate events. In your case there really is no reason to wait for
> > the
> > Create to complete and then fire an event. Instead, just let the create
> > return back and then pass the new Order to your Email object. I wouldn't
> > email right from the Create either as this is starting to break the
> > encapsulation of your Order object. Emailing an order is something that
> > should be performed by an Email object instead.
> >
>
>