Building from the work done in Part 1 and Part 2, we are now ready to implement a front-end to our CQRS/ES system.

For this demo, the front end will be an ASP.NET Web API application, and we'll be using Microsoft's Unity container to provide Dependency Injection and use the Service Locator pattern.

Defining and Using the Runtime

The first thing we need to do is create a runtime in which our CQRS/ES app will execute. That runtime, further, needs to override a method so that it returns a SQL Server Event Store rather than the default LocalEventStore. Finally, the runtime must be hooked into SimpleCQRS's own Unity implementation. The runtime looks like this:

With these two pieces in place, we are ready to start defining our Controllers.

Defining the Controllers

Because we are using Dependency Injection, we need to define our Web API Controller classes in a specific way so that SimpleCQRS and Unity will properly inject the desired dependencies. Here's a skeleton for MovieController:

Now, we must think about what kinds of dependencies MovieController has. In a "normal" application, MovieController might well have a dependency on a Repository or Service class, but in our implementation neither of those exist at this level. Instead, MovieController has a dependency on the Command Bus we talked about in Part 3, and we need to set up the controller such that this dependency is resolved when the controller instance is created (aka "constructor injection"):

There you have it! We've got a fully-functional CQRS/ES application, with a Web API front end, and a full event store. In the next and final part of this series we'll add some more events and commands, specifically ones that implement changes being made to an already-existing Domain Object, as well as list some drawbacks of this particular solution.

If you'd like to see the code I built for this series, check out the GitHub repository.