hi i wanna pass the textboxquantidadehoras.Text;datahorado.SelectedDate; correto.Desenvolvedor(from childwindow) to a grid in the main page called datagridhorastotais but i can't set the itemsource to "teste" form child window... any ideas? here is the code of the childwindow
public partial class ChildWindow2 : ChildWindow, INotifyPropertyChanged
{
public class Horas : INotifyPropertyChanged
{
private string quantidadehoras;
private DateTime? datahora;
private string desenvolvedor;
public string Quantidadehoras
{
get
{
return quantidadehoras;
}
set
{
quantidadehoras = value;
NotifyPropertyChanged("Quantidadehoras");
}
}
public DateTime? Datahora
{
get
{
return datahora;
}
set
{
datahora = value;
NotifyPropertyChanged("DataHora");
}
}
public string Desenvolvedor
{
get
{
return desenvolvedor;
}
set
{
desenvolvedor = value;
NotifyPropertyChanged("Desenvolvedor");
}
}
#region
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged(string propertyName)
{
if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
public class Horas2 : ObservableCollection<Horas>
{
public Horas2()
{
}
}
}
#endregion
public ChildWindow2()
{
InitializeComponent();
}
public class quadrodehorarios : ObservableCollection<ChildWindow2>, INotifyPropertyChanged
{
}
private void OKButton_Click(object sender, RoutedEventArgs e)
{
Horas2 teste= new Horas2();
Horas correto = new Horas();
correto.Quantidadehoras = textboxquantidadehoras.Text;
correto.Datahora = datahorado.SelectedDate;
correto.Desenvolvedor =textboxDesenvolvedor.Text;
this.DialogResult = true;
}
private void CancelButton_Click(object sender, RoutedEventArgs e)
{
this.DialogResult = false;
}
private void comboBox1_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
}
private void textboxqtdhoras_TextChanged(object sender, TextChangedEventArgs e)
{
}
}
}
I’m working up my chapter on the “Event Aggregator” pattern for my book this evening and I’m starting by collecting my thoughts on the subject. If you feel like you have to comment and give me free advice for this chapter, then I guess you should do that (please). I’ve written about the pattern before here and here. I’m also referencing some other patterns that I haven’t written much about yet. Ward Bell and John Papa have both blogged on these patterns. I’ll blog about my StoryTeller implementation tomorrow night.
In case you’re new to the pattern, the Event Aggregator object will:
Channel events from multiple objects into a single object to simplify registration for clients.
In essence, it’s a specialized form of the GoF Mediator pattern. It’s a “hub” object in your application that you can use to do decoupled “publish/subscribe” messaging between different parts of your application. I’ve used the pattern with WinForms apps, WPF with StoryTeller, and even JavaScript in web pages (going to be very important as we implement a dashboard pattern for our web app at work).
Here’s my braindump on the pattern:
Registration. Somebody has to be responsible for registering the listeners with the event aggregator hub.
You could have the listeners themselves do the registration by taking a dependency on the event aggregator as is idiomatic with Prism. This is great because it makes it obvious when looking at a class whether or not it is registered as a listener. I’m not a fan of this approach because I think it’s awkward and adds repetitive code to each listener – and repetitive code should be stamped out wherever it pops up.
You could use another object like a “Screen Activator” (more on this pattern later) to do the registration of ViewModels/Presenters, screens, or non-UI elements as listeners. This has the advantage of removing the responsibility of bootstrapping away from the class (ViewModel/Presenter/service) that does the real work.
This is really just 2a, but you could use a custom “Registry” class to make the explicit subscriber subscriptions in one place. I like
Use conventional registration with an IoC tool to automatically add objects to the event aggregator as appropriate. I use a marker interface plus a StructureMap “interceptor” to do this in StoryTeller. This is the “easiest” mechanically, but adds some overhead to understanding how the pieces connect. But, and there’s a big but, conventions are black magic rather than explicit code.
Discoverability/Traceability. An event aggregator is a form of indirection, and indirection almost always makes a system a little harder to understand. At some point you definitely need to understand what objects are publishing and which are receiving events. Strong typed events are a boon here because it’s relatively easy to use advanced IDE features like R#’s “Find Usages” to quickly determine publishers and subscribers to a particular type of event. The event aggregator analogue in CAB depended on string keys and made troubleshooting harder. Event aggregator implementations in JavaScript and other dynamic languages will have the same issue.
Diagnostics. For those of us using static typed languages, you might want to add a diagnostic report that can be generated on demand that can scan the codebase and identify publishers and subscribers based on a dependency on the event aggregator. Using marker interfaces or common super types for message classes can make the diagnostics much easier.
Event Filtering. Simply put, not every subscriber cares about every instance of a type of event. For example, StoryTeller has several widgets that need to respond to every single test event (queued, executing, finished), but the individual test screens only respond to events involving their one particular test. In this case you need to worry about how events are filtered. The responsibility for the filtering can be in:
The listener itself. The listener knows what it cares about, so let it decide whether or not to continue processing the event.
Filter within the EventAggregator itself. You can either register the listeners with a subject like this: EventAggregator.Register(this, myTest), but this is assuming a specialized event aggregator that “knows” about the subject. Another way is to make the registration with a Predicate or Func to filter within the event aggregator. I’m still experimenting here inside StoryTeller with this pattern a little bit.
I’m thinking about having either an IoC interceptor or a Screen Activator do the filtered event registration. Again, the point is to move the grunt work of setting up the screen out of the ViewModel/Presenter to keep the ViewModel/Presenter relatively clean
Thread Marshalling. It’s very handy to just let the event aggregator take care of marshalling callbacks to the screen back to the UI thread. The Prism Event Aggregator gives you fine grained control over whether or not the marshalling should take place. Maximum control might be nice when every bit of performance matters, but then again, it makes you error prone in a part of the code that is hard to test.
Queuing. At this point I let the StoryTeller EventAggregator just process things synchronously, but running the event publishing on a background thread or queuing events up may be necessary to conserve resources.
Open/Closed Principal. Using the Event Aggregator makes it much, much easier to add new features to your system without modifying existing code as you would have to if you were dependent upon direct communication without an event aggregator. This is an important issue for teams doing incremental delivery or cases where multiple teams are working on the same system in parallel.
Garbage Collection: Your event aggregator has to keep a reference to all the subscribers. This can present you with some serious memory leak issues as screens are closed, but not garbage collected if the event aggregator is keeping a reference. You can beat the issue by using WeakReferences internally inside your event aggregator. The other option is to explicitly un-register listeners. The WeakReference strategy may be more reliable, but has its own issues. Explicit un-registration isn’t that bad if you are using a “Screen Conductor” to manage the screen activation lifecycle. Much more on that later…
Event Latching. Two issues here:
It might be valuable to ignore events at times. I’m specifically thinking about the case of a screen on a tab that is not active/displayed. Let’s say that this screen receives an event about financial market data being updated. The act of updating the hidden screen’s display turns out to be very expensive in terms of resources. You might want to quietly ignore or “latch” events when a screen is deactivated and hidden. That of course adds some complexity to make the hidden screen “know” to update itself when it is activated again. I think this is where the “Screen Activator” and “Screen Conductor” patterns come into play. If there’s a standard workflow that happens whenever a user activates a tab, then the “screen activator” should get an Activate() call.
In some specialized cases you may want the Event Aggregator to “latch” itself while in the midst of responding to an event. This is especially important when a widget responding to an event publishes other events. Think about “change” events getting published during the act of binding a screen to new data. In this case the event aggregator should ignore new events until the first is completely finished.
Event Ordering. It might be important that events be completely processed in the order that they arrive to the event aggregator. For example, Chad & I had an issue last year with a subscriber receiving an event, then publishing other events that were processed before the original event reached all of its subscribers. There might be a code smell in there somewhere, but event ordering may be something you need to consider.
One size does not fit all: It can often be advantageous to have multiple event aggregators within one application. I often find it useful to use an event aggregator that is scoped within a single complex “Composite View” when a single screen is very complicated within its own right.
Instrumentation. The EventAggregator is effectively a message bus and has all the same advantages as a message bus. Sending all events through the event aggregator gives you a great centralized place to put instrumentation code. Less repetitive code == fewer mistakes and better productivity.
What about the Prism EventAggregator?
Many people first come into contact with the Event Aggregator pattern through the implementation in Prism. For my regular readers you may be shocked (shocked I say!) to know that I don’t particularly care for the way they implemented the pattern in Prism. I think the Prism implementation is clumsy and awkward to use. I despise that idiom of first getting the event aggregator, then retrieving an “Event” object that I’ll then listen to. Same thing with publishing. I think it’s awkward that I have two steps (get event, then publish) instead of just saying “IEventAggregator.Send().” All of that is unnecessary noise code, and the “get event, then listen/publish” adds a little bit of overhead to every single unit test that I write that involves either listening to or sending events (more mock object setup, and that would add up more than the extra production code). No, that’s not a huge deal, but noise code adds up, and every bit of ceremony/noise code I can remove due to infrastructure will make me more productive and the code easier to deal with by making it easier to read.
All I want is to go:
IEventAggregator.Send( the message ). Nothing else.
The listeners should have little or preferably NO/ZILCH/NADA coupling to the event aggregator.
I think Prism is far better than CAB, but it’s still headed for some of the same problems that CAB had. The complexity and awkwardness of the EventAggregator in Prism is directly caused by trying to make the EventAggregator generalized to every possible scenario that you can think of. You will be able to create a better implementation of EventAggregator for your application by tailoring something simpler for only the things you need. At a minimum, you could at least put an application specific wrapper around Prism’s generalized API’s to make them easier to consume. I think you could stand to sacrifice some of the flexibility of the Prism EventAggregator and end up with a simpler to consume alternative.
Don’t take this as a specific criticism of Prism itself, because the real issue is that generalized application frameworks are an automatic compromise. The single most important reason that Prism is better than CAB is that you could easily, and I do mean easily, roll your own Event Aggregator and replace the one in Prism while still using the rest of Prism. Hooray for “Composition over Inheritance.” You couldn’t do that with CAB.
Wiki:
God willing and the river don’t rise, I will have a public Wiki up for the Presentation Patterns book by the end of the weekend. On advice from multiple people, I’ll be writing most of the first draft on the public Wiki. I’ll announce it as soon as it exists.
If I understand what you are trying to do... You could use a Mediator pattern such as the Event Aggregator to communicate an event (the data selection) from the childwindow to the parent window. Here is a StackOverflow question that covers the Event Aggregator.
Related
I need to fire the SpeechRecognizedEvent manually for unit testing so I can't use the EmulateSpeech Method from a SpeechRecognitionEngine
Edit:
I have already encapsulated the SpeechRecognition into a separate Class with its own interface to mock it.
I need to call the Event because I have an AutoResetEvent, which I Set() during the event. The Unit test needs this to proceed.
The general idea with unit tests is not to use real things as they either:
Slow (e.g. database)
Dangerous to poke to often (e.g. Google Search API)
Not available (e.g. web service or hardware)
For such scenarios you suppose to use mocks/stubs. In other words things that behave identically, but in reality under your full control.
In your case SpeechRecognitionEngine, even if it might be available, would be too cumbersome for unit tests. Who/what would speak things to it? And even if you trigger an event, why to instantiate an instance of real SpeechRecognitionEngine?
Looking at MSDN for SpeechRecognitionEngine definition indicates that it doesn't implement an interface, which means it would be difficult to mock/stub.
For this case, you need to wrap, in other words, encapsulate SpeechRecognitionEngine into your own class which implements your interface. Then, all you need to do is to have two implementations of your interface, one with real SpeechRecognitionEngine for a real speech recognition, and another class for unit tests, which would just mimic your own callback, instead of using SpeechRecognized event.
You just swap one instance for another, and your code won't see a difference, as they are implementing single interface.
If you just want to simulate an event, you just call an event handler, as this is a method. Or another method, if you can't create some EventArgs. But the problem is that you'll have to expose inner methods from outside of your class (e.g. mark it public or internal), and this does looks nasty.
private void recognizer_SpeechRecognized(object sender, SpeechRecognizedEventArgs e)
{
this.ProcessSpeechRecognition(e.Result);
}
public void ProcessSpeechRecognition(RecognitionResult result)
{
// your logic here
}
Then in test you just call something similar to the below:
ProcessSpeechRecognition(new RecognitionResult { Text = "test" });
Despite posting an answer before that describes best practices for TDD; here is an answer specific to SpeechRecognitionEngine.
Microsoft has already thought about emulation of speech recognition. Here is MSDN article for SpeechRecognitionEngine.EmulateRecognize Method:
https://learn.microsoft.com/en-us/dotnet/api/system.speech.recognition.speechrecognitionengine.emulaterecognize
I have a class that Handles send & receive over a socket between my application and the network. This class uses other classes, including a low level sockket connection class and a PDU handler class that creates the messages to send and handles received data.
Now i use an event to signal my class that the low level connection class has data for it and i need to send that data to the PDU handler to convert to information the application can use and then hand the data to the application.
For future usage, i am trying to get the class to be as generic as possible, so that on future Server/Client projects i will need only to change the PDU handler to take under consideration the new operations availlable and how to handle the data.
All that is well underway and now i am facing the isssue of handing the data back to the app. For that, my logical approach is an event letting the app know data is ready for collection. For that i can either:
a) have one event and let the app sort out what kind of message it is through the operation code (doable)
b) Have one event per operation code and have the app subscribe to all of them and thus know at start what it is getting
Considering the idea of making things generic, and the approach stated in b, is there a way to dinamicly create events based on a given delegate signature at runtime?
e. g.
imagine you have opcodes in an enum called MyOperation1 and MyOperation2 and you have defined a delegate like:
public delegate void PDUEventHandler(ParamType Param, [...]);
and i want to define events called:
public event PDUEventHandler MyOperation1;
public event PDUEventHandler MyOperation2;
But if i add a new operation code i will need an event for it.
Can this events be created dinamicly or do i need to do it by hand?
If i need to do it by hand then i guess a single event would be better and handle things app side.
Perhaps what you need is a callback - essentially you pass to the event handler a delegate for it to execute when the handler is done. Here's a stackoverflow thread to give you an idea
In terms of event handlers & re-useability, perhaps you can extend EventArgs and have that delegate as a property.
EDIT:
I was thinking a single PDUEventHandler having common code and a "hole" where custom code is run. That custom code is passed to the handler as a delegate (i.e. a method) or even a class instance. But let's change that a little...
Sounds like you need a factory. In fact you're practically describing a factory.
Conceptually let go of the idea of passing special opcodes to an EventHandler per se, or having multi-signature PDUEventHandlers.
Create a PDUHandlerFactoryclass. The factory returns a customized instance as a general PDUHandler class reference. Then instead of a PDUEventHander you caller has a PDUHandler reference that points to the factory-custom instance.
I'm understanding how events work in C# (am a fair newbie in this field). What I'm trying to understand is why we use events.
Do you know a well coded / architected app which uses events?
To provide a concrete normal world example....
You have a form, the form has a listbox. There's a nice happy class for the listbox. When the user selects something from the listbox, you want to know, and modify other things on the form.
Without events:
You derive from the listbox, overriding things to make sure that your parent is the form you expect to be on.
You override a ListSelected method or something, that manipulates other things on your parent form.
With events:
Your form listens for the event to indicate a user selected something, and manipulates other things on the form.
The difference being that in the without events case you've created a single-purpose class, and also one that is tightly bound to the environment it expects to be in. In the with events case, the code that manipulates your form is localized into your form, and the listbox is just, well, a listbox.
What would be very useful is a non trivial example of an app which uses events (guess it really helps testing too?)
Thoughts so far are:
Why use Events or publish / subscribe?
Any number of classes can be notified when an event is raised.
The subscribing classes do not need to know how the Metronome (see code below) works, and the Metronome does not need to know what they are going to do in response to the event
The publisher and the subscribers are decoupled by the delegate. This is highly desirable as it makes for more flexible and robust code. The metronome can change how it detects time without breaking any of the subscribing classes. The subscribing classes can change how they respond to time changes without breaking the metronome. The two classes spin independently of one another, which makes for code that is easier to maintain.
class Program
{
static void Main()
{
// setup the metronome and make sure the EventHandler delegate is ready
Metronome metronome = new Metronome();
// wires up the metronome_Tick method to the EventHandler delegate
Listener listener = new Listener(metronome);
ListenerB listenerB = new ListenerB(metronome);
metronome.Go();
}
}
public class Metronome
{
// a delegate
// so every time Tick is called, the runtime calls another method
// in this case Listener.metronome_Tick and ListenerB.metronome_Tick
public event EventHandler Tick;
// virtual so can override default behaviour in inherited classes easily
protected virtual void OnTick(EventArgs e)
{
// null guard so if there are no listeners attached it wont throw an exception
if (Tick != null)
Tick(this, e);
}
public void Go()
{
while (true)
{
Thread.Sleep(2000);
// because using EventHandler delegate, need to include the sending object and eventargs
// although we are not using them
OnTick(EventArgs.Empty);
}
}
}
public class Listener
{
public Listener(Metronome metronome)
{
metronome.Tick += new EventHandler(metronome_Tick);
}
private void metronome_Tick(object sender, EventArgs e)
{
Console.WriteLine("Heard it");
}
}
public class ListenerB
{
public ListenerB(Metronome metronome)
{
metronome.Tick += new EventHandler(metronome_Tick);
}
private void metronome_Tick(object sender, EventArgs e)
{
Console.WriteLine("ListenerB: Heard it");
}
}
Full article I'm writing on my site: http://www.programgood.net/
nb some of this text is from http://www.akadia.com/services/dotnet_delegates_and_events.html
Cheers.
You can implement the Observer Pattern in C# with Events and Delegates.
Here is a link to an article that describes such: http://blogs.msdn.com/bashmohandes/archive/2007/03/10/observer-pattern-in-c-events-delegates.aspx
At the most basic conceptual level, Events are what let the computer react to what you do, rather than you being required to react to what the computer does. When you're sitting in front of your PC with several applications running (including the operating system), and several clickable objects available in each context for you to choose among, Events are what happens when you choose one and all the pieces involved can be properly notified.
Even moving your mouse around kicks off a stream of events (to move the cursor, for instance).
You could always build your own way of sending/receiving events, subscribing/unsubscribing to event sources. But the language gives you a simple/standard way of doing it, so that is a good reason to use language "events" instead of your own events technique.
Also, using the language "events" allows you to do all kinds of cool things using reflection because it is standardized.
As to why using an event technique at all. There are all kinds of real-life examples where this is quite usefull and simpler to use events. Events are almost similar in their usefullness than Windows Messages are.
If you are confused on why use events when we can achieve the same functionality with delegates, then the answer is :
the client (the class where subscription occurs) cannot directly call the invoke method on the delegate when using events
instanceOfClassWithDelegate.sampleDelegate.Invoke(); // not possible with events
the client cannot list or clear the functions assigned to the delegate when using events
instanceOfClassWithDelegate.sampleDelegate = null; // not possible when using events
events are a better way to encapsulate logic as is implicitly understood
The entire credit to this answer goes to this blog : https://dev.to/willydavidjr/why-use-events-instead-of-delegates-in-c-40k8
This question is related to C#, but may be applicable to other languages as well. I have a reservation against using code such as the following:
using System.Windows.Forms;
class MyForm : Form
{
private Timer myTimer;
private Button myButton;
public MyForm()
{
// Initialize the components, etc.
myTimer.Tick += new EventHandler( myTimer_Tick );
myButton.Click += new EventHandler( myButton_Click );
myTimer.Start();
}
private void myTimer_Tick( object sender, EventArgs eventArgs )
{
myTimer.Stop();
// also, I see a lot of usage of
// Timer.Enabled = true/false instead of -^
myButton_Click( this, ea /* or event EventArgs.Empty, or null */ );
return;
}
private void myButton_Click( object sender, EventArgs eventArgs )
{
// do a lot of stuff, with lots of logic that doesn't even use the
// state of the eventArgs
return;
}
}
Am I alone, in that the above style is a pet peeve of mine? Are there others who enjoy the clarity of separating event handling from the workload of functions, or even separating out complex routines into separate functions?
Is there even an accepted style? I feel like any expressiveness and flexibility that event handling in C# has can be lost with styles like this. I feel like if you have a method that means "a button has been clicked", then it should only be called when a button is clicked.
To those who write like this, I would say: if you insist on having an EventHandler method to handle your timer tick, and your button click, then call it something other than button_Click -- perhaps "handleUserEvent( object sender, EventArgs eventArgs )".
Really, though, the question is, are there any style guidelines that are widely used which either support or discourage usage such as the above?
This is definitely not a "personal preference". There is a clear, well-understood approach of how to write code that is well-structured, maintainable, reusable, and understandable. Each method in your code should encapsulate a single piece of reusable functionality. The structure of your code should be:
void ButtonClickEventHandler(...)
{
UserData userData = //determine user data from event data
DoUserThing(userData);
}
void DoUserThing(UserData userData)
{
//do stuff
}
void SomeOtherMethod()
{
UserData userData = //get userdata from some other source
DoUserThing(userData);
}
(This is a very loose example. In a proper application everything should be separated into different classes by concern.)
I agree with Rex M's answer, but I'd take it one step further. If you are using the MVC pattern (or something similar), the view would delegate the button click to the controller. The controllers methods can of course be called from elsewhere in your class - say, from your timer callback.
So, back to your original code:
using System.Windows.Forms;
class MyForm : Form
{
private Timer myTimer;
private Button myButton;
private MyController myController;
public MyForm()
{
// ...
// Initialize the components, etc.
// ...
myTimer.Tick += new EventHandler( myTimer_Tick );
myButton.Click += new EventHandler( myButton_Click );
myTimer.Start();
}
private void myTimer_Tick( object sender, EventArgs eventArgs )
{
myTimer.Stop();
myController.SomeMethod()
}
private void myButton_Click( object sender, EventArgs eventArgs )
{
// All the stuff done here will likely be moved
// into MyController.SomeMethod()
myController.SomeMethod();
}
}
One advantage of using MVC is the decoupling of the controller from the view. The controller can now be used across multiple view types easily and exiting GUIs are easier to maintain as they contain very little application logic.
EDIT: Added in response to comments from the OP
The fundamental design principals of software engineering talk about coupling and cohesion. Importantly we strive to minimise coupling between components while maximising cohesion as this leads to a more modular and maintainable system. Patterns like MVC and principals like the Open/Closed Principal build on these fundamentals, providing more tangible patterns of implemenation for the developer to follow.
So, anyone who writes code as seen in the original post has not understood the fundamentals of software design and needs to develop their skills considerably. The OP should be commended for identifying this "code smell" and trying to understand why it's not quite right.
Some relevant references:
http://en.wikipedia.org/wiki/Coupling_(computer_science)
http://en.wikipedia.org/wiki/Cohesion_(computer_science)
http://en.wikipedia.org/wiki/Loose_coupling
http://en.wikipedia.org/wiki/Model–view–controller
http://en.wikipedia.org/wiki/Design_patterns
http://en.wikipedia.org/wiki/Open/closed_principle
http://en.wikipedia.org/wiki/Design_Patterns_(book)
myButton.PerformClick() is probably slightly nicer, if you don't need to pass eventargs. Sometimes you just want to simulate a click.
But yes, I would agree that it's nicer to move the real code into another function. I prefer my event handlers to be very simple - just connect the UI to the logic, which is elsewhere.
Then you can rearrange and redesign your UI without worrying so much about where the logic is.
This code increase the chance of problems if another coder works on the myButton_Click method.
What if I came in to adjust the implementation of the myButton.Click handler? I might assume that the sender object is a Button, and try to cast:
Button b = (Button)sender;
I have no knowledge without reading the rest of the class implementation that I'm not always receiving a Button as the sender.
So my point is: -1 for maintainability, because of breaking the assumptions of what objects will be passed as myButton_Click parameters.
The short answer is that why would you simulate a button click by calling the handler directly? If you want to wire both methods up to the same event, you would just wire it up. Event handlers are multicast delegates, which means you can add more than one of them. Wiring up an event more than once is totally acceptable.
myTimer.Tick += myTimer_Tick;
myTimer.Tick += myButton_Click;
myButton.Click += myButton_Click;
Whether or not this is a WTF is an engineering call that we can't make from a short code snippet. However, based on your comments, it smells like a WTF. Forms or any UI should never handle business logic. They need to be business-logic-aware to some degree (as in validation) but they don't encapsulate / enforce the logic themselves.
Going further, following some simple practices as basic refactorings and using a layered (n-tier) approach to software will take you a long way, and you will realise along the way that the code you presented smells bad.
Eventually you'll come across some high-level patterns like MVC (model-view-controller) and MVP (model-view-presenter) which go a step beyond the simple layering. If you follow them you get a good separation of concerns.
I agree with the accepted answer, but jumping right into 'Use MVC', here's some code that doesn't illustrate MVC, without explaining why is a little cargo-cult for me.
The special things about events in C# (and the .Net framework in general is the delegate, which is the C/C++ equivalent of a function pointer. the method attached to the event itself is not special in any way and should be callable from anywhere.
Update:
perhaps I should have been more verbose, but I thought my use of "should" instead of "can" or "may" would be enough. It is my assertion that event handlers should be called when the functionality they implement is needed, instead of having them become wrappers to methods that "do the work" the less method calls you have in the stack the better you will be, specially with the performance implications of .Net's exception handling.
I know it's a long time since this was asked but I'm going to differ and say no. As long as (1) it works and (2) it's clear what it does. I've heard all the standard arguments about design principles and such but think sometimes people go overboard and forget about the basics of design in not making things overly complicated. I see this in people forcing OOB where procedural design is really more suited as well.
One response is to move the code elsewhere and instead call that function but the problem with arbitrarily moving code is it creates unnecessary duplication making it more complex and less readable which is the opposite of good design. Following the approach of having one function do one thing people end up having to call a bunch of functions from multiple places only really succeeding in creating more opportunities for errors and additional overhead.
I believe this is what's responsible for all of the bloat we're seeing in buggy programs. I'm rather from the school of reusing and grouping as much as what makes sense and if that includes calling a function directly instead of indirectly where it makes sense and does the same thing then that can actually improve readability and decrease complexity.
I have an app which consists of several different assemblies, one of which holds the various interfaces which the classes obey, and by which the classes communicate across assembly boundaries. There are several classes firing events, and several which are interested in these events.
My question is as follows: is it good practice to implement a central EventConsolidator of some kind? This would be highly coupled, as it would need to know every class (or at least interface) throwing an event, and every consumer of an event would need to have a reference to EventConsolidator in order to subscribe.
Currently I have the situation where class A knows class B (but not C), class B knows class C, etc. Then if C fires an event B needs to pick it up and fire its own event in order for A to respond. These kinds of chains can get quite long, and it may be that B is only interested in the event in order to pass it along. I don't want A to know about C though, as that would break encapsulation.
What is good practice in this situation? Centralise the events, or grin and bear it and define events in each intermediate class? Or what are the criteria by which to make the decision? Thanks!
Edit: Here is another question asking essentially the same thing.
You could put the event itself in an interface, so that A didn't need to know about C directly, but only that it has the relevant event. However, perhaps you mean that the instance of A doesn't have sight of an instance of C...
I would try to steer clear of a centralised event system. It's likely to make testing harder, and introduced tight coupling as you said.
One pattern which is worth knowing about is making event proxying simple. If B only exposes an event to proxy it to C, you can do:
public event FooHandler Foo
{
add
{
c.Foo += value;
}
remove
{
c.Foo -= value;
}
}
That way it's proxying the subscription/unsubscription rather than the act of raising the event. This has an impact on GC eligibility, of course - which may be beneficial or not, depending on the situation. Worth thinking about though.
What you could try is using the event brokering of either NInject or the Unity Application Block.
This allows you to, for example:
[Publish("foo://happened")]
public event EventHandler<FooArgs> FooHappened;
[Subscribe("foo://happened")]
public void Foo_Happened(object sender, FooArgs args)
{ }
If both objects are created through the container the events will be hooked up automatically.
I'd probably try to massage the domain so that each class can directly depend on the appropriate event source. What I mean is asking the question why don't A know about C? Is there perhaps a D waiting to emerge?
As an alternative approach you could consider an event broker architecture. It means observers don't know directly about the source. Here's an interesting video.
This would be highly coupled, as it would need to know every class
I think you answered your own question if you consider that coupling is bad! Passing events through a chain of potential handlers is a fairly common pattern in many environments; It may not be the most efficient approach, but it avoids the complexity that your suggested approach would involve.
Another approach you could take is to use a message dispatcher. This involves using a common message format (or at least a common message header format) to represent events, and then placing those messages into a queue. A dispatcher then picks up each of those events in turn (or based on some prioritisation), and routes them directly to the required handler. Each handler must be registered with the dispatcher at startup.
A message in this case could simply be a class with a few specific fields at the start. The specific message could simply be a derivative, or you could pass your message-specific data as an 'object' parameter along with the message header.
You can check out the EventBroker object in the M$ patterns and practises lib if you want centralised events.
Personally I think its better to think about your architecture instead and even though we use the EventBroker here, none of our new code uses it and we're hoping to phase it out one sunny day.
we have our own event broker implementation (open source)
Tutorial at: http://sourceforge.net/apps/mediawiki/bbvcommon/index.php?title=Event_Broker
And a performance analysis at: www.planetgeek.ch/2009/07/12/event-broker-performance/
Advantages compared to CAB:
- better logging
- extension support
- better error handling
- extendable handlers (UI, Background Thread, ...)
and some more I cannot recall right now.
Cheers,
Urs