Onion, more on signals

I've been trying to think through every type of feature I can that people might want in an application, and then seeing if I can think up a way of implementing it using signals. A couple of days ago I thought up something I couldn't implement using the exact approach I had.

I once wrote an app that had a treeview on the left hand side, the user could drill down to a customer of their choice and then when they clicked on that customer the display would update and show their details. This made me realise that a simple "SelectCustomer" signal would not be sufficient, what I actually needed to do was to have multiple SelectCustomer signals and indicate which customer to select.

The changes I have decided to make are as follows:

1. I will introduce a struct called SignalCreateParameters. This will hold a string property "Parameters" which may be used to automatically populate some of the properties of the created signal, ie the customer identity.
   
2. The signal factory will first be asked to populate a list of SignalCreateParameters, and then ultimately the target will be provided the opportunity of modifing that list, so that it may add additional items, remove them etc.
3. Neither the signal factory or target will have GetSignalPermission. Instead the SignalCreateParameters will have a SignalPermission property so that individual customers may be disabled, removed etc within the list.

I've also decided that I really don't like having an ISignalFactory. I really don't like having to write two classes each time I want to add a single new "thing". Having to write two classes for each new feature is prone to error in my opinion, so I've been looking at using reflection again.

I originally used reflection but decided against it because it required the developer to

1. Identify that the class is a signal (interface or attribute)
2. Implement certain methods as static methods with a specific name + parameter list.

I went for the SignalFactory class approach so that I could create a base class and allow the developer to inherit from it, this would make it very clear which methods needed to be implemented. However I think that the penalty of developing two classes each time outweighs the time it takes to learn the method signatures required (1 constructor + 1 optional method).

So I think I will now remove the ISignalFactory part of the framework. The only thing I really need to consider is performance. On my 2.Ghz laptop executing a static method directly 1 million times takes 31 milliseconds, whereas via reflection it takes 2,109 milliseconds. This would mean that if there were 1,000 signals and 1,000 simultaneous requests the process would take 2.1 seconds per user. I don't suppose that is too bad really, if anyone has anything further they think I should consider then I'd like to hear from you. Just write to my droopyeyes.com email address (support@)