The ServiceActionResult Pattern. Part Two

Continuing from my previous post The ServiceActionResult Pattern
This could also be implemented in a Generic Repository Pattern. If you have read, any post about a using a generic repository, it usually looks something like this:

The interesting part is the Update/Delete/Insert methods.
Yes… you could return a boolean saying whether or not the transaction was successful.
But we could also use the ServiceActionResult “Pattern”, to make it look something like this;

Which gives us that nice granular return state AND the actual entity in question (which is nice for RESTful services)

The ServiceActionResult pattern

This is not a GOF pattern or anything, but it’s very nice and brings alot to the table.
Basically what I do is this;
Whenever I have some sort of Service/Repository or something similar. Basically any façade where I delegate to CRUD or do CRUD, I return a ServiceActionResult.
The ServiceActionResult class looks like the following:

It’s just a basic generic class that holds a class (T) and an Enum.
The Enum could look something like this, but could be anything you’d like.

It’s kinda like REST.
Return the entity and an HTTP Status code, but instead of a statuscode, we return a ServiceActionStatus
Below you’ll see basic usage:

Using the above. The caller of the CarService just needs to Switch on the ServiceActionStatus and can easily handle, lots of different types of responses.

Showing messages to users with Toastr and SignalR, the perfect match.

Toastr
Sending updates/messages to users can sometimes be a pain in the butt, but using signalR can provide an enormous relief to exactly this matter.
Often times one would have a controller method which would return some sort of JsonResult (or View) containing whether or not the transaction went well. Using SignalR in conjunction with Toasts, we can write an a single implementation that will work for all of your future actions as well.
No more coding ajax success/failure for every single action.

Prerequisites:

  1. An MVC Project
  2. A BaseController
  3. SignalR package from nuget
    • Install-Package Microsoft.AspNet.SignalR
  4. A Toast implementation
    • //cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js
      //cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/css/toastr.min.css
  5. A razor _layout

Once you have everything installed and up and running you are ready to implement SignalR

SignalR Backend implementation

Once the package is installed it should create a startup.cs file – if it doesn’t go create one.
It should look like this

Now we are ready to create the Hub. In SignalR the hub is what ties together connections and messages sent.

Once done, create a MessageEmitter – this will send Toasts through SignalR

Notice I’m using an enum for ToastType

Now we are about ready to send Toasts to our users.

SignalR Frontend implementation

Now for the razor layout page.
Standard SignalR connection and then showing the toast when it is received.

Using this whole ordeal

To actually send a toast message to the user.
simply call the BaseController method from earlier ShowToastMessage()

What now?

You could implement a GlobalErrorHandler attribute and a custom ToastException to throw on controller errors.
it could look something like this


it would then be used by throwing a new ErrorToast, which in turn would send an error HTTP status code (500) to the client AND show an error Toast.
You can now handle ajax errors, along with successes.