LazyCache: Caching Service for ObjectCache

LazyCache ObjectCacheI recently blogged about in-memory caching while I was looking for a library to sit on top of .NET ObjectCache or MemoryCache.

Alastair Crabtree commented on my post, suggesting I take a look at this LazyCache library.

So I figured I would take my existing demo application and port it to using LazyCache.

As with most of my posts, all the following code is available as a demo application on GitHub.

This demo console app is going to show currency exchange rate between USD and CAD for a given day.


Lazy cache is a simple in-memory caching service. It has a developer friendly generics based API, and provides a thread safe cache implementation that guarantees to only execute your cachable delegates once (it’s lazy!). Under the hood it leverages ObjectCache and Lazy to provide performance and reliability in heavy load scenarios.

Since it uses ObjectCache under the hood and by default it will use MemoryCache.Default.  It has all the expiring features of ObjectCache.

This means you can specify a CacheItemPolicy, which allows you to expire on a specifc DateTimeOffset, Timespan Expiration, as well as gives you Update/Remove callbacks.

So for this demo, I’m only going to simply use the Timespan expiration for invalidating a cached item after 30 seconds.


First we can start off by creating a new instance of an CachingService.

Next, I want to create a method that is going to query for the exchange rate. But before it does, I want to check the cache to see if it exists.

The beauty with of LazyCache is the GetOrAdd method which returns the existing item from your cache or calls the provided delegate Func<T> which will return the object you want to cache.

Now to write this all up, I’m going to take a date as input from the console application and have it invoke our GetCurrencyRate(DateTime).


Now when we run our application, we can see that if we request the same date, within the last 30 seconds, we will hit the cache instead making our HTTP call.


  1. Requested 2016-01-01, 2016-01-02, 2016-01-03, 2016-01-04, all of which were fetched from HTTP service.
  2. Request 2016-01-01 which is fetched from the HTTP service because it exceeded 30 seconds between the first call for that date.
  3. Request 2016-01-04 which returned from cache.


The other interesting aspect of LazyCache is that since it can take an ObjectCache in it’s constructor, this opens the door to using it with Redis ObjectCache.

Let me know if you have any comments related to LazyCache or other caching libraries in comments or on twitter.

Source Code

GithubThe source code for this demo is available on GitHub.

Web API: Resource Model isn’t your Data Model

Web API: Resource Model isn't your Data ModelI 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.


A good illustration of the above is with how you see most examples of using OData with .NET and Entity Framework.

The problem lies that the model being exposed via Web API/OData is your backing Entity Framework data model.

In this case, your Data Model (Table) is your Object Model (C#) is your Resource Model (OData).

The Problem

There are a couple issues with exposing your data model.

The first one is pretty apparent the moment you need to start changing your data model.

Having the consumers of your API being loosely coupled poses some challenges when you change the backing model.

If you are creating a public API, you have no control over the clients.  And if the app is internal and you do control the clients, it can still be a nightmare updating them to work with your new data model.


You could make the argument that you need to version if you are going to change your data model.  There are a numerous ways you can attempt to version your API.

I’d recommend having a listen to Sebastien Lambla (SerialSeb) talk on “Versions are Evil How to do Without in your API“.

Resources not Objects

I think of resources in an Web API as being about features or capabilities rather than objects.

For example, say this was our product data model:

When thinking about a product as a resource, I would likely want to more data.  I tend to drive a resource by the consumer.

Our backing model likely has other related data.  For example, a product may have a “AvailableToPromise” field which indicates available quantities.

So now our Product resource is starting to diverge from our data model.


I tend to follow a CQRS style approach to Web API’s. For me, commands and queries are resources.

In regards to a Product, we likely have the ability to do some sort of Inventory Adjustment (command).  I would expose the Inventory Adjustment command as an endpoint and provide that endpoint with our Product Resource.

This way the consumer can start navigating and sees other available resources.


Web API’s and hypermedia are something I’m trying to understand more of and how I can create better Web API’s.

Let me know if you have any comments related to Web API’s either in comments or on twitter.

.NET CLI Basics

I started looking at the .NET Core CLI (Command Line Interface) a bit more over past couple weeks and figured I’d put together a blog and video covering the basics.

I’m intentionally covering only the basics because the CLI is currently at “Preview 2” and is not yet RTM.

Also, since we know the project.json is being eliminated before RTM, I didn’t want to dig into aspects like multi targeting different platforms and frameworks since that requires the project.json.

Video Walk Through

I’ve created a short video which explains everything this post will, so if you prefer video walk through this is for you:


The first thing you need is the .NET Core SDK for Windows.  The new vanity domain for .Net is now

If you head on over there, you can download .NET Core SDK for Windows.

There are a other downloads on this page, specifically you can get the Visual Studio Update which will include .NET Core.  For the purpose of my example, since the intent is NOT to use full blown Visual Studio, just download the .NET Core SDK For Windows.

You can install the SDK with all the defaults.


The easiest way to get usage information on the CLI and various commands is with



From here you can see all the common commands.  For each command, you can generally type “dotnet [command] –help” to get usage infromation about a specific command.


An example of this would be for the “new” command.  The new command creates the required files for a new .NET Core project.  Basically creating scaffolding for your new project.  If you are familiar with Yeoman, this is similar.

To get usage information on the “new” command we would type:

dotnet new --help

.NET CLI New Command


Since .NET Core is package based with NuGet, the natural next step is to restore all the NuGet packages for your new project.

This command is basically using NuGet under the hood.

You can specify where the restored packages will be placed but by default the .nuget/packages directory in your users home directory will be used for caching.

In my case, on my local machine this would be:



Once you’ve restored all your dependencies, you can now run your app.

The run command is just a shortcut for building and executing your application in one step.  The run command uses the build command prior to launching your application.

The run command is used in the context of your project directory and not the built output in your bin directory.  Meaning you would run “dotnet run” from your project directory.

C:\Users\Derek\HelloWorld>dotnet run

If you wanted to run the HelloWorld.dll in your bin directory, you would execute:

C:\Users\Derek\HelloWorld>dotnet bin/HelloWorld.dll


As you can expect this builds your application into Intermediate Language (IL) in the form of a DLL.

Even if you are creating a .NET Core console application, it will not generate an EXE by default.

An EXE would be generated if you are creating a self-contained .NET Core application, but by default the build process creates a portable application (dll) which can be run by any maching that has .NET Core installed.
Let me know if you have any comments and interesting experiences with the .NET CLI via Twitter or the comments section on my site or YouTube.