Hello there! Today’s the last day of the month! I’m so very excited to announce that I was able to unbeer for 30 out of 31 days! That’s some accomplishment, a personal best for me :) I hope the trend continues into the next month.
Now to the updates in the application.
Code for this post is in branch: learning-unbeered-7.
- Previous hand written command/handler/processor implementation kind of worked and was good enough for the state of the project. However I’ve been wanting to look at MediatR. Also, its probably a smart idea to spend my energy writing application code rather than trying to write some infrastructure.
- Added MediatR as a replacement for current command processor. MediatR has two basic concepts, making a request and sending a notification. A request is sent to one specific handler, while as the name implies, a notification can be sent to multiple handlers. To align with the namings, I’ll start using the term request instead of command. Both request and notification are messages. A request message, a notification message! When I have a specific task to accomplish, I send a request message(command) to a specific place(handler). However, when I have a notification message, I can just yell my lungs out and I don’t really care if anyone is listening or not! I usually like to think that a request handler is the one that notifies of what just happened. i.e a handler completes the requested task, and then publishes a notification message saying ‘I just did something’.
- I’ve re-structured the files in the Journaling project again :) Folder names reflect what code resides within it. For eg. Data contains models that represent actual data and our helper database class. I’ve renamed Commands to Requests. This contains the actual classes that represent action/command/request to perform. Handlers contains the handlers of the requests! ViewModel contains classes that represents model in the view.
- Added icrosoft.Extensions.DependencyInjection and Scrutor as a choice of Dependency Injection(DI) framework. Here’s a great article on what and why of DI pattern. Using this pattern we can tell MediatR where to find all of our handlers so that when it is ready to process a request or a notification, it knows about which handlers to dispatch the messages to!
- When the program starts up, BuildMediator scans the assembly to register all of our handlers to DI container such that when MediatR needs them later, they are available.
- To send a request, we simply use Send method on the MediatR instance.
Now that we have an infrastructure for elegantly handling request and notification messages, we can do some interesting stuff! For eg. when a new entry is added, we can “notify” that we’ve successfully “added a new entry”. We can call this notification message “NewEntryWasAdded”. With this notification in place, we can easily add in new features like ‘send a tweet’, ‘email my sister’, ‘calculate total beers in a year and update cache’. Each feature is implemented as an individual handler and performs one specific task! Don’t want ‘email my sister’ feature after a month? Just remove it, I don’t even have to change any other code :)
- We have implemented couple of requests, so lets try to get into notification!
- I still think we can replace the static class DataStore with something better.
Until next time, Namaste!