CQRS

I was recently reminded of some troubles I had awhile ago which were caused by exposing my data model. This tweet by Mike Amundsen brought up some thoughts that I had yet to share, and why I now suggest that you don’t expose your data model. remember, when designing your #WebAPI, your data model is not your object model is not your resource model is not your message model #API360 — Mike Amundsen (@mamund) August 21, 2016 OData A good illustration of the above is with how you see most examples of using OData with .NET and Entity Framework. The problem lies… Read More »Web API: Resource Model isn’t your Data Model

I’ve previously blogged about Nancy.Linker, the URI Builder for NancyFX.  However, I wanted to take it a step further and give an actual example of how I handle linking to Nancy routes through my application. Organize by Feature I organize my application by features.   Features are generally commands or queries.  They are either returning data (queries) or actions that represent behaviors (commands). This means that I generally only have one route per feature.  Since I organize by feature, this means that I put the Nancy module with the single route and then all subsequent code (commands or queries, handlers, models) in that… Read More »Linking to Nancy Routes

In my previous post, I created a few extension methods for Hangfire and MediatR in order to enqueue an IRequest. However, it was not following Hangfire Best Practice. The purpose was to have the IRequest serialized entirely when calling Enqueue(), which would be stored in Hangfires storage. Then when the request would be invoked, Hangfire would deserialize the IRequest and call Mediators Send(). My functioning example worked as expected. However, Hangfire recommends making your job arguments small and simple. Best Practice Method invocation (i.e. a job) is serialized during the background job creation process. Arguments are converted into JSON strings using the TypeConverter… Read More »Hangfire Best Practice: Invoke by ID