Different pieces of code in a bot application
A controller controls what happens with a message as soon as the user has sent it to the bot. I wouldn’t say that most of the action happens within the controller, but there definitely wouldn’t be any action without it. Below you can see what such a controller looks like in terms of code. Depending on the application, this file will be adapted along the way.
But let’s first take a look at what’s inside. In the first lines, we declare what namespaces we need. For instance we need the functionalities of Microsoft.Bot.Connector. Without these declarations, we wouldn’t be able to use the classes or methods in these namespaces.
Then, we declare what namespace and what class this file belongs to. But although our code would not work without it, it’s not where the magic happens. That happens in the Post() method, where the activity is checked for being a message. If it is a message, then a RootDialog is launched. Which basically means that the code in the RootDialog file (in the Dialogs folder) is ran through. However, an activity doesn’t have to be a message. It can have different types and those should be handles as well. This is where the HandleSystemMessage() method comes in. Within this method you can define what happens if the user is deleted, typing, the conversation is updated, …
So to summarise, if you make adaptations to the controller, you will most likely change the Post() method. Or you can add a second controller, for instance to control proactive messages.
The dialogs in your bot applications are crucial for the functionality of your bot. Dialogs specify what action is performed upon receiving a specific message. Here, you can for instance include Microsoft LUIS, a natural language processing tool. If you’d like to know more about LUIS (and LUIS action bindings), then you might be interested in my previous blog.
So as you can see, I again included the code in the RootDialog for an empty bot application. Again, you can see the namespace we need, followed by the class we’re in and the first method StartAsync(). This method looks very simple, maybe even unnecessary, but try to leave it out and the code doesn’t work anymore. What StartAsync() does is the following: it waits for the MessageReceivedAsync() method to complete. This is crucial since in the latter method you define what reply the bot will give to your message. What happens here? Well, the bot waits for the activity (message) to come in, and then it calculates the length of the message and then replies to the user with what he/she just said, together with the length of this message. Then, finally, it starts listening for a next message.
A helper is usually nothing more than a part of the code that could’ve been put in a dialog, but most likely the developer decided that in terms of overview and readability of the code, that piece is better off in a helper file. So a helper usually extends a method in a dialog with additional functionalities or a completion of the functionality that a method in the dialog tries to achieve. In other words, you decide whether you need helpers or not, mainly based on whether code is readable and workable (1000nds of lines of code in a file is not very workable).
In a model you can define what you need in a dialog or helper. It literally is a model for something. For an example, see the file below, which is a model in one of our applications (Donnabot, a personal assistant to schedule meetings in Outlook).
This model can later be used to build a list of meeting rooms, as you can see in the code below. You can declare a new MeetingRoom() and fill in the specifications that you defined in the model. This list can then be used in a method that for instance decides what meeting room is assigned to which meeting request.
this blog was originally posted here.