ForEvolve

In the past few months, I worked on a few projects, some are more long terms than others but all in all, I ended up adding a few features to my toolbox: the ForEvolve Framework.

This article will focus on ForEvolve.AspNetCore.Localization. I will show you how you can enable localization of DataAnnotations error messages with 3 lines of code. All the usual Asp.Net Core 2 localization plumbing is also done for you.

In the previous article, we completed the last piece of the Ninja API. In this article, we will glue all of these pieces together by:

• Creating integration tests to integrate the Ninja subsystem confidently
• Connecting the Ninja API to Azure Table Storage
• Leveraging the new Asp.Net Core 2.0 default configuration

It is now time to complete our Ninja subsystem!

To be prepared, in the previous articles, we implemented a mapping subsystem and visited the Façade design pattern, we also created our data model and introduced Azure Table Storage.

In this article:

1. We will implement the NinjaRepository
2. We will connect the NinjaRepository to Azure Table Storage (which cost basically nothing)
3. I will introduce an open source framework that I am building; from that framework, the ForEvolve.Azure package will help us get things done faster than using WindowsAzure.Storage directly.

In the previous article, we explored Azure Table Storage briefly, and we created the NinjaEntity class. Doing so opened up a new concern: mapping Ninja to NinjaEntity.

Before going further, to keep the external dependencies low, in this article, we will create a mapping system. This will also allow us to explore an additional design pattern: the Façade.

So far, we implemented the clan’s feature, using a static in-memory storage. We also implemented most of the ninja feature, excluding the data-access logic, where we stopped at the INinjaRepository level.

In this article I will introduce you to Microsoft Azure Table Storage and we will create our data model. This article will be brief.

In the previous article, we defined most of the ninja sub-system and implemented the NinjaController while in the next article, we will implement the repository, talk about Azure Table Storage and the ForEvolve Framework.

You could see this article as 6.2 since I originally planned to write a single article for both the NinjaController and the NinjaService. Due to its size, I decided to split it in two.

In the previous articles, we covered all the patterns needed to create a system where each responsibility is isolated. We implemented a Controller, a Service and a Repository. We also created unit and integration tests covering our specifications (as basic as they were). Our Clan sub-system is pretty basic indeed, but it allowed us to learn the patterns without bothering too much about external dependencies.

In this article we will define most of the ninja sub-system and implement the NinjaController while in the next articles, we will implement the service, the repository, talk about Azure Table Storage and the ForEvolve Framework.

Revisiting all the patterns in a more complex subsystem should help you learn them. Do not worry; I will also add a few more concepts along the way, this is not a copy/paste of my previous articles.

In the last article, we talked about the service’s role, we completed the ClansController implementation, and we created more unit tests to keep improving the quality of our Ninja App.

Now it is time to attack the Repository Pattern, create the IClanRepository interface, complete the ClanService implementation and create the default ClanRepository class with, of course, more unit tests.

In the last article, we built the empty ClansController. We also created a failing test for its only action. That test is testing our expectation of the ClansController.ReadAllAsync() action. However, since our action’s body is composed of only that one line: throw new NotImplementedException();; it cannot pass.

In this article, we will focus on the services part of the patterns. To do so, we will create the IClanService interface and its default implementation, the ClanService class. In the process, we will update the ClansController and ensure that its test pass. As you may expect, we will also create unit tests for the ClanService class.

In the first article, we visited a few concepts that we will apply, starting in the current article.

The second article was an overview of Dependency Injection.

In this 3rd article, we will:

• Model the ninja
• Create the ClansController (ninja’s don’t fight alone!)
• Write some tests

All of this will get us ready for the next article’s ClanService.