In this article we going to look into designing the data providers, the third layer of the tri-layer architecture.

Providers are responsible for "proving" tools to a service. Things like handling data operations (SQL or LINQ queries), working with files, network requests or sending emails are the responsibilities of the providers. Every provider should have an abstraction (a set of interfaces) that is called by service and should never be accessed directly.

Email or Identity providers are self-descriptive. Their structure is straight forward: interfaces and their implementations. Please see README for more information.

Data providers are more complicated and required further explanation. The main idea is to isolate high level business logic from a specific database implementation or even a data query implementation. It provides a flexibility in decision making process about choosing the database engine, replacing it if needed or maybe not using a database at all.

In this article we are going to apply Consumer->Service->Provider architecture to the Web API ASP.NET Core application. Please see the previous article describing fundamentals of this architecture.

The typical .Net Core Web API project Visual Studio project contains “Controllers” folder, Startup.cs and Program.cs. If authentication is chosen, it creates database model and “Migration” folder in the same project. This is a perfect project structure for the start.

As development progresses, the controllers “grow” to the enormous size. They call EF code directly, execute queries, send emails etc. It may help a little to move reusable code to “the BaseController” and every controller can be inherited from it. However, it would complicate providing of sufficient unit testing coverage (if any). This is when Consumer->Service->Provider comes to rescue.

This article introduces the sample app: a basic ASP.NET Core project with three layers architecture: Consumers, Services and Providers. This is the first article of the series of articles about structuring ASP.NET Core projects. The following articles in this series will dive into details of the implementation: project structure, service boundaries and responsibilities, unit testing strategy, designing database providers, using EF, etc.

LogScope is not yet another logger. It is an extension of existing logging libraries that provides alternative way of logging and measuring a performance of critical parts of code. It also helps building a cleaner picture of executing asynchronous calls. It can used along with any existing logging provider.

The whole idea is based on a logging scope. Based on IDisposable interface, scope:

1. Logs it instantiation and disposal;
2. Can log lines as part of the scope;
3. Can be created from logging manager or as part of another scope (a nested scope);

UI development requires asynchronous operations to implement snappy behavior. Sometimes debug is not the best option. For my Blazor app, I wanted to trace some of method calls if needed. Searching internet didn’t reveal any existing lightweight solution. So, I came up with a simple log scoping solution based on IDisposable.

Few months ago, I have stumbled upon some article online about Blazor a new web browser based framework from Microsoft. Blazor allows to run applications written in .Net instead of Java Script. Which makes it quite different from "traditional" frameworks like Angular. Blazor runs on web assembly and provides the ability to build rich web applications. I've been working with ASP.NET Core and Angular for quite some time. Despite the fact I'm a big fun of the .NET/Angular combination, there is one thing that always bothers me: you have to keep the same model objects in C# and TypeScript and serialize/deserialize in json to pass from client to server and vice versa. Having client and server running in the same framework potentially saves tremendous amount of work related to client-server interoperability. So, I decided to give it a try.

One of the common tasks in building CRUD client application is getting data from the server and displayed to the client in some sort of data presentation: list, form, etc. Usually, retrieved data is stored in the internal memory so it can be presented multiple times without re-retrieving it from the server: cache.

Angular based client is no different in this case. This article is about simple class Cacheable<> that helps managing cache of data retrieved from http server or other any other source. This class can:

• Trigger “get data” request when no cache available
• Store retrieved data in the cache
• Get data to the client as Observable
• Reset cache

Please see final version with example how to use it on Plunker.

It is hard to build application with Angular without taking advantage of Observables. There is a bunch examples of handling http requests using them in the web.

Sometimes we need to use them to handle simple values. In the case it is usually implemented in a service. Service has to provide Observable reference so components can subscribe for the updates. It requires at least two members declared in the service: Subject & Observable. Having half dozen observables in the service produces a dozen of declaration and makes code cluttered.