Noob Question: Why raise envents instead of executing event code?

[(Pete Cresswell)]

I've been perusing a "real-life" application and notice that for instance, in a
button's Click() event, they don't write the processing code. Instead, they
raise an event like AddNewRecord and then put the coding that would have been in
the click event in the AddNewRecord event handler.

It seems TB throughout the app, so I'm guessing it's some sort of Best Practice.

Anybody care to explain?
--
PeteCresswell

[John Spiegel]

Hi Pete,

This can often be seen as a question of style or what the application calls
for. There are two main reasons I might do this. One would be to separate
out the business rules from the interface. The other would be that there
might be multiple objects that have some reason to care that the button has
been clicked. By raising the event, any other subscribed eventhandler would
be able to also take action. Although, I believe eventhandlers could
subscribe to the button's click event rather than it having to spawn a new
one.

HTH,

John

"(Pete Cresswell)" <x@y.z> wrote in message
news:gu********************************@4ax.com...

I've been perusing a "real-life" application and notice that for instance, in a button's Click() event, they don't write the processing code. Instead, they raise an event like AddNewRecord and then put the coding that would have been in the click event in the AddNewRecord event handler.

It seems TB throughout the app, so I'm guessing it's some sort of Best Practice.
Anybody care to explain?
--
PeteCresswell

[Nick Malik]

I doubt that this is a best practice. I've certainly never heard of this as
any kind of best practice.

an event that fires an event, sounds like the author wanted to play with
events.
Code for the sake of code usually adds unneeded complexity. That increases
the cost of maintenance and increases the liklihood of errors.

There are some elegant ways to seperate business rules from UI. Event
indirection isn't one that comes to mind.

Regardless, if you have to keep this code working, and it is already
working, no point in changing it. Stick with the model in this app.

Just try not to learn from it.

My $0.02
--- Nick

"(Pete Cresswell)" <x@y.z> wrote in message
news:gu********************************@4ax.com...

I've been perusing a "real-life" application and notice that for instance, in a button's Click() event, they don't write the processing code. Instead, they raise an event like AddNewRecord and then put the coding that would have been in the click event in the AddNewRecord event handler.

It seems TB throughout the app, so I'm guessing it's some sort of Best Practice.
Anybody care to explain?
--
PeteCresswell