views:

103

answers:

5

I have a Windows Form project that I've just started. On the form I have a listbox that I'm loading with Products. When someone double clicks a Product, I want it to raise a ProductChanged event. Other things in my project will subscribe to this event and update things like other parts of the GUI when the Product changes.

My question is, where should the event be and who should raise it? Should the event be on the form and be raised by the listbox's double click handler? Or should I set it up where the event is in my Products class and the listbox calls a method on this class to let it know that the product has changed. And then the Product class will raise the event? Or should it be done another way?

+1  A: 

The product changed is a UI event, it would make sense if its raised on the form, and the other UI elements suscribe to the event.

AlbertEin
+1  A: 

The listbox should be raising the event since that's whose Product has changed.

GaryF
A: 

Depends on what your event signifies. If the intent is to notify subscribers that the Product object was modified, then it belongs to the Product class and should be fired by a code inside that class. If the intent is to notify that another Product object was selected, then it belongs to the view that manages the list of Products (your listbox/form).

Franci Penov
A: 

Most developers have a poor understanding of how to properly design an application using events (beyond the OnClick stuff).

The following .NET book is for you:

http://www.amazon.com/Event-Based-Programming-Taking-Events-Limit/dp/1590596439/

I highly recommend it.

therealhoff
A: 

The name ProductChanged implies that the event is fired while the product has been changed. I would raise the event in the product class, because in that case each change will trigger the event. If you trigger it in the GUI, and later add (for example) import functionality, chances are that you forgot to fire the event after the change.

Gamecat