Giving users immediate response in Event Driven Architecture

Question

I have been reading a lot about Event Driven Architecture and it makes a lot of sense to me, but the issue of giving users immediate feedback is confusing me.

Say there is a service ('EmployeeService') that holds a list of all employees. The business logic for creating an employee is located in this service.

The UI from another system uses this service. The requirement is (whether you like it or not) that it has a grid of employees, and an 'add employee button' which brings up a form, and when you submit the form, it returns you to the gird with the new employee in it. The grid show derived fields which are calculated by the service (this is important to note!).

Traditionally, on submit, I would have displayed a loading screen, synchronously sent a WCF request to register the employee, and when that had completed, and forwarded to the grid (which would definately by now have the new employee).

With EDA, on submit, I would 'fire and forget' a command to register the user - but then what? I could forward to the grid but there is a chance the new employee might not be in there yet? I could manually add to the grid assuming all will be OK, but how do I display the derived data calculated by the service? Or maybe I could have a 'new employee pending graphic' displayed on the grid if it has not been created yet, then make the page check back every few secons until it has?

This is a common scenario so what is the common solution for this?

Answer 1

You can register a callback when sending the command and block until the command is complete.

If you've downloaded the NServiceBus package, just reference the AsyncPagesMvc3 sample solution. It has an example of exactly what you're looking for.

Answer 2

If your EmployeeService is a SOA service then the Add Employee Button also belongs to the EmployeeService. The user interface is simple a composite of multiple services. You can deploy part of the EmployeeService locally on the client which handles the employee creation and the calculation (if the calculation is not a complex one).

For example:

public class AddEmployeeView
{
   public IBus Bus { get; set; }    

   public void AddNewClicked() {
        // async calculate
        // store directly in the employee service database
        // or dispatch command internally
        // refresh employee list as the service is the only owner of that data
        Bus.Publish<NewEmployeeAdded>(m => { });
   }
}

So the above AddEmployeeView belongs to the EmployeeService. The EmployeeService alone has knowledge how to calculate and store new employees (even in its own database) and is the only logical publisher of the NewEmployeeAdded event. And here goes away your complexity.