Out of curiosity, I have declared an Event Table in a .cpp file, is it still possible to use Connect in the same .cpp file at other function calls?
Yes, of course, why not. It is even possible to use both event tables and Connect() or Bind() for the same object, and while this is not recommended because it can be confusing, it does work in a well-defined way: first, the dynamic (i.e. those connected or bound with the corresponding function) event handlers are considered and if none of them handles the event, then the search continues with the event table entries.
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
I know how to use the FileSystemWatcher class, and I know how to send the message I want to send. What I can't figure out is where to initialize the FileSystemWatcher.
I'm assuming that there's some place to initialize an Endpoint where I could set this up, but I'm not certain where that would be.
Seems like this would be a common use-case; I'm a little surprised that Udi hasn't built this into NServiceBus!
Yes that is built into NServiceBus.
You need to implement a class that derives from IWantToRunWhenBusStartsAndStops.
See http://docs.particular.net/nservicebus/the-nservicebus-host#custom-initialization-and-startup for more info.
I'm going to try the following and tell you if it worked:
Create a FileWatcher class with
a. a static boolean variable 'keepChecking'
b. a static method watchFiles() which initiates the FileSystemWatcher and then stays alive with a loop that tests the keepChecking
b. the OnChange etc. FileSystemWatcher event handlers
- which upon being triggered by the FileSystemWatcher, presumably send out NServiceBus events
To start the watcher (in my NSB Host program) You run the WatchFiles() method in a separate thread in a starter class which inherits from IWantToRunWhenBusStartsAndStops.
To stop the watcher you first set the watcher.EnableRaisingEvents to false then set the keepWatching to false so the loop ends.
A similar approach in this StackOverflow question with code:
NServicebus with File System Watcher from Tylor Day.
Except that he unified the starter class with the filewatcher class and its (non-static) creation method running in the same thread. Interestingly it works without the need for a keepalive loop, since the FileSystemWatcher event-subscription is defined as static.
He was told that this is not the best way to go and was given two suggestions: a. To use a "satellite class" or b. To move the whole thing to a separate class, making the fileWatcher itself static. No mention of a keepalive loop. I'll try that too.
In my current project, there are lots of networking code, and it use the event handler to handle the input message. Is this mechanism different with the call back function ?
Typically not much. The handler is usually used in the context of a UI application where the UI control will call the handler to handle a UI event. The callback function is traditionally used from the C days (Function pointers) and also in the C++ (Functors) world.
As a general concept I would say that the call back functions are primarily used for Asynchronous execution. Where for example, client side function must look something up on the server and it may take a while. So instead of blocking it says :"Call back at this number (myCallBackFunction) when you are done looking up stuff on the server".
Now event handlers are just that: they handle some predefined events. Usually they wait for users to do something like click a button and then they spring into action. They typically but not necessarily expect some sort of input.
Hope this helps.
I'm conducting a test using JOlivers CommonDomain and EventStore with NServiceBus. I need to raise an event in my Aggregate like this:
RaiseEvent(bus.CreateInstance<IPhoneNumberChanged>(m => { m.Number = number; }));
And then later i have this handler:
private void Apply(IPhoneNumberChanged phoneNumberChangedEvent)
{
this.Number = phoneNumberChangedEvent.Number;
}
Unfortunately this doesn't work. I get an exception: "CommonDomain.Core.HandlerForDomainEventNotFoundException: Aggregate of type 'Phone' raised an event of type 'IPhoneNumberChanged' but not handler could be found to handle the message.".
The problem here is the object created from "bus.CreateInstance" since it works with pure concrete classes. But I need my events as interfaces. Can this be solved?
EDIT: Just a note - I don't have to use "bus.CreateInstance" to create the object, it's just the easiest (only) way I currently have to raise the 'IPhoneNumberChanged'. Any other way would also be great - just as long as I have an interface as argument in the handler.
In your constructor for your Phone aggregate, simply add the following:
this.Register<IPhoneNumberChanged>(this.Apply);
That will take care of the exception. The default internal routing mechanism inside of the CommonDomain is a registration-based router than understands how to get an event to the appropriate Handle method--all without using reflection. Another router has been written and is already part of the CommonDomain project which uses reflection and is more convention based.
One quick thought regarding your event name. Rather than saying that the phone number changed, you may want the event to indicate why the phone number changed. From a domain perspective, the why of something is always more interesting and important that the what. The fact that a phone number changed usually isn't interesting. The fact that it changed because the person moved or cancelled their account or whatever--that's interesting and very likely important as well.
I'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.