What is new in CQRS.NET 2.0
We are very excited to announce the release of CQRS.NET 2.0!
This is one of our largest releases yet. It is jam-packed with a whole bunch of new, fantastic features. Supporting and deploying to Microsoft Azure was our biggest/main focus with this release. We’ve started to keep track of what we’re planning on doing with our broad level roadmap.
Proper akka.net support.
You can now leverage those AKKA skills along with the benefits of Actors directly within CQRS.NET! Both aggregates and event handlers can now enjoy all the benefits of strong concurrent handling via AKKA.NET. While modelling, just select “AKKA.NET” or “Built In” depending on your needs. If you are writing your code by hand, have a look at the test project over at github!
Simplified SQL support for data stores and event stores.
We’ve added a simplified Linq2SQL Data Store and Event Store. So long as your events and entities are simply with only simple properties this will save you heaps of time. If you still want complex objects, we recommend sticking with our original SQL Data Store and using Entity Framework.
Updated MongoDB support for data stores and event stores.
We now created a new package “Cqrs.MongoDB” for use with MongoDB 3.x and .net 4.5. The main reason this package was made was to switch to “MongoDB.Driver” package.
We’ve kept the original MongoDB package “Cqrs.Mongo” for MongoDB 2.x and .net 4.0.
ASP.NET Web API support.
We’ve created a new package “Cqrs.WebApi” for use with WebAPI and SignalR. While modelling you can now notate that an event should be sent via SignalR.
Configurable ability to control soft or hard exception handling when a received command or event fails.
New dynamic web.config and app.config settings exist to control if event and command handling should follow a whitelist or blacklist mode. In whitelist mode, when an event or commands arrives if the it cannot be deserialised it will not throw an exception, unless configured to. In blacklist mode, all events and commands (unless configured otherwise) will ALWAYS throw an exception if the it cannot be deserialised.
The main mode setting is
<add key="Cqrs.MessageBus.BlackListProcessing" value="true/false" />
The event and command configuration settings follow a basic naming convention
<add key="MyProject.MyNamespace.MyEventOrCommandName.IsRequired" value="true/false" />
MemoryCache event store for testing and short lived aggregates.
A simple Event Store that uses the .net System.Runtime.Caching.MemoryCache class to act as a short lived event store. This is useful when you have batch processing where transient events don’t warrant persistence after a period of time. The obvious example is testing, but there are a few cases where events and commands are used, but storing them isn’t required as the process as a whole has a wider reaching event.
SendAndWait commands (strongly not recommended, but highly requested none-the-less).
The command publisher now has a SendAndWait method that lets you specify the type of event you expect to be raised. This is useful when you want to fire a command, asynchronously hold the thread and associated resources waiting for an aggregate to raise an expected event to continue execution. It’s not a great pattern, but when enough people ask for something …
Public and private event and commands buses.
There are now two event and command buses. A public and private bus. This is useful when you have internal events as part of your business and process flows that you don’t want external clients to be aware of.
Support for multiple write connection strings to allow for data replication (e.g. write to three servers globally but read from only the one closest to you for performance and redundancy).
To greatly simplify high availability, redundancy and performance CQRS.NET can now internally take care of replicating/mirroring data stores across multiple servers. In short, we asynchronously write to multiple servers and read from one. This means you read from your clostest/fastest server but ensure writes are mirrored to all servers.
Added Telemetry tracking with Azure ApplicationInsights.
We’ve added telemetry tracking using Azure ApplicationInsights. You can now track command and event handling throughput. We’ve even done some stress testing on a typical Azure deployment, the results of which we’ll release soon.
Added Azure service and event hubs for event and command buses.
Azure ServiceBus and Azure EventHubs can now be used as event and command buses. This change is so large we’ll cover it in separate blog posts.
Added Azure table and blob storage for data stores and event stores.
Azure blob storage and table storage can now be used as event stores and data stores.
A new Domain Driven CQRS.NET project/solution template in the Visual Studio gallery… look for it by searching CQRS from the “New project” dialogue when starting your next project.
We’ve uploaded a blank, Domain Driven Design (DDD) CQRS.NET solution to the visual studio gallery. When creating your next project, use the search tool at the top right of the “New Project” dialogue and enter “CQRS”. Start with all configuration pre-set-up and modelling with UML ready to go.
Heaps of bugfixes.
Heaps and heaps of bugfixes… we lost track of how many. We’ll get much better at tracking them in subsequent versions.