Is there an accepted "name" for an event that simply reports back a "message"

I have a "DataImporter" class [takes data from many sources and processes it] that I want to report back through an event when it "does something". At the moment I have: DataImporterStarted DataImporterCompleted DataImporterImportedData DataImporterDeleted

But they all do the same thing...report back a simple string saying "Data Importer started at xx:xx" or "DataImporter Imported xxx Rows" etc.

Should I be keeping the events separate, or is there an accepted pattern/naming convention for this kind of "I'm doing something" event? Thx

I was trying to avoid code like this:

var importer = new DataImporter();
importer.DataImporterStarted += new DataImporterStartedEv开发者_如何学CentHandler(importer_DataImporterMessage);
importer.DataImported += new DataImportedEventHandler(importer_DataImporterMessage);
importer.DataImporterCompleted += new DataImporterCompletedEventHandler(importer_DataImporterMessage);
importer.RunDataImporter();

---

You could use something like create a DataImporterProgress event with a Action property like "Updated" or "Deleted" (an enumeration) and a Message string in it's eventArgs property.

---

As Adam already mentioned it would be easier to distinguish between these events for other classes, because every listener will only receive these kinds of events he liked. But if you think that everyone who subscribes to one of these events has to subscribe to all of them then it wouldn't make sense to make such a bunch of different events.

If you like to merge them, you are on your own. But maybe you can get some inspiration from the INotifyPropertyChanged and the ListChanged event, cause they are also some kind of aggregators for different kind of things that could happen. But this leads to the fact that the client has to inspect the incoming data from the event and make has maybe to throw away a lot of incoming events, cause they are out of interest.

---

I would keep them separate as suggested in other answers, too.

To avoid duplication of the handling code, you could setup your events with compatible signatures. That would allow you to register the same event handler function to all events.

I don't know if this make sense in your case. It depends on the context.

---

Events are rather heavy weight for this king of task, especially if the frequency is high. Even though I'm not directly answering your question, I want to give you an alternative to the event based solution:

The solution involves event streams using Rx Framework, and exposing and IObservable(T) instead of an event.

The solution goes like this: the DataImporter class will expose an IObservable<string> property, which internally is implemented by a Subject<T> which will be used to raise events.

public class DataImporter {
    private Subject<string> _StatusSubject = new Subject<string>();
    public IObservable<string> Status { get { return _StatusSubject; }
    ...
}

How to raise an event in the stream:

void Foo() 
{
    // Do some work
    _StatusSubject.OnNext("Some work has been done!")    
}

How to subscribe to the event stream:

var importer = new DataImporter();
importer.Status.Subscribe(message => Console.WriteLine(message));

The advantage of using this approach is that you can use Linq operators to perform operations on the event stream in a very simple and straightforward manner. Ex:

// Filter the stream of events, only to show short messages
importer.Status
        .Where (message => message.Length < 100)
        .Subscribe(message => Console.WriteLine(message));    

// Add a timestamp to status messages
importer.Status
        .TimeStamp()
        .Subscribe(timestamped => Console.WriteLine(String.Format("Time:{0} Message: {1}", timestamped.Timestamp, timestamped.Value)));    

// Buffer status messages each 5 secconds and return a list of messages
importer.Status
        .BufferWithTime(Timespan.FromSeconds(5))
        .Subscribe(list => Console.WriteLine(Strin.Join(new[] {Environment.Newline}, list));

And many more ...

---

I would say it is a nice thing to keep the events specialized, as long as they provide the according infrastructure (for example, where DataImporterCompleted's event args would offer nothing more, DataImporterImportedData's would provide the list of row that were just imported).

Other than that, if you want extremely simple functionality with just some status string, you can do something like:

public event Action<string> StatusUpdate;

You raise it with:

StatusUpdate("some status string");

Your handlers will look like:

void HandleStatusUpdate(string status)

Or you can use the standard .NET pattern:

class MyEventArgs: EventArgs {}

public event EventHandler<MyEventArgs> MyEvent;

And so on...