stream:// .net

This week, .NET 5.0 was officially released. Read about how you can get more out of your .NET investments on AWS and some of the services and tools that we have worked on to support  .NET 5 on AWS. In this post we show how you can use the AWS Toolkit for Visual Studio to […]

.NET 5 is now released! .NET 5 is the next version of .NET Core and the future of the .NET platform. With .NET 5 you have everything you need to build rich, interactive front end web UI and powerful backend services.

The Observer Pattern is at the core of reactive programming, and observables come in two flavors: hot and cold. This is not explicit when you are coding, so this article explains how to tell the difference and switch to a hot observable. The focus is on hot observables. The concepts here are relevant to all languages that support reactive programming, but the examples are in C#. It's critical to understand the distinction before you start doing reactive programming because it will bring you unstuck if you don't. Please support this blog by signing up for my course Introduction to Uno Platform. Reactive Programming It's hard to clearly define what Reactive Programming is because it spans so many languages and platforms, and it has overlap with programming constructs like events in C#. I recommend reading through the Wikipedia article because it attempts to give a history of reactive programming and provide objective information. In a nutshell, reactive programming is about responding to events in the form of sequences (also known as streams) of data. Technically, any programming pattern that deals with this is a form of reactive programming. However, a pattern called the Observer pattern has emerged as the de facto standard for reactive programming. Most programming languages have frameworks for implementing the observer pattern, and the observer pattern has become almost synonymous with reactive programming.  Here are some popular frameworks: RxJS (JavaScript)  System.Reactive(.Net) ReactiveX (Java oriented - with implementations for many platforms) RxDart (Dart) The concept is simple. Observables hold information about observers who subscribe to sequences of notifications. The observable is responsible for sending notifications to all of the subscribed observers. Note: The publish-subscribe (pub/sub pattern) is a closely related pattern, and although technically different, is sometimes used interchangeably with the observer pattern. Hot Observables Hot observables start producing notifications independently of subscriptions. Cold observables only produce notifications when there are one or more subscriptions. Take some time to read up about the observer pattern if you are not familiar. If you start Googling, be prepared for many different interpretations of the meaning. This article explains it well and gives examples in C#. This article is another good article on the topic of hot and cold observables. A hot observable is simpler because only one process runs to generate the notifications, and this process notifies all the observers. A hot observable can start without any subscribed observers and can continue after the last observer unsubscribes. On the other hand, a cold observable process generally only starts when a subscription occurs and shuts down when the subscription ends. It can run a process for each subscribed observer. This is for more complex use cases. Hot Observable Use Case Let's imagine the simplest use case. The notification publisher is a singleton. It gets instantiated when the app starts and will continue to poll for information throughout the app's lifespan. It will never shut down, and it will send notifications to all instances of the subscriber that subscribe to it. In C#, observers implement the IObserver<> interface, and observables implement the IObservable<> interface. This is an implementation of the use case in C#. We create the publisher with CreateObservable(), and then two subscribers subscribe. They both receive the notification Hi repeatedly until they unsubscribe, or we can cancel the task. This is a hot observable because the long-running task runs independently of the subscribers. Note: this is not the recommended approach. This is just an example for clarity. View this gist on GitHub Reactive Extensions The reactive extensions are a set of C# helpers for building observables and observers. They exist in the namespace System.Reactive. Their home is in this is repo. You can use it by installing the System.Reactive NuGet package. It would help if you used these extensions instead of directly implementing IObservable<> or IObserver<>. Reactive frameworks for other platforms have similar libraries.  Cold Observables Observable.Create from the reactive extensions creates observables. What the documentation doesn't tell you is that the observable is cold by default. The code that you supply doesn't run unti...

Note: Part two of this guide is now available here! Recently, I’ve been listening to a lot of SomaFM internet radio streams while I work as they have a lot of terrific commercial-free programming. One day while being creatively inspired by the Sonic Universe station’s offerings, I had the idea...

The web development community has come a long way since the early days of the web. Building interactive web experiences can leave many developers in a state of paralysis. What web framework should we use? What transpiler should create my assets? Do I go with React or VueJS? So many questions that we need to answer. For folks who work on the back end of the technological stack, or for people who only focus on HTML and CSS, rejoice!

gRPC and .NET are fast. Explore the many performance improvements in gRPC and .NET 5.

C#9 introduces record to define immutable data classes with a consice syntax. Learn to use records and avoid common mistakes.

This tutorial introduces several architectural and design patterns that can be used to implement common scenarios in .NET desktop and mobile applications.

Memory problems in a big .NET application are a silent killer of sorts. Kind of like high blood pressure. You can eat junk food for a long time ignoring it until one day you face a serious problem. In the case of a .NET program, that serious problem can be high memory consumption, major performance issues, and outright crashes. In this post, you'll see how to keep our application's blood pressure at healthy levels.

The Null Object Pattern is a pattern that uses objects with null behavior instead of performing null checks throughout the codebase. ILogger and ILoggerFactory are dependencies that often require a lot of null checking, so they are perfect candidates for the null object pattern. Suppose your classes take ILogger or ILoggerFactory as a dependency, and you are not using the null object pattern. In that case, you will probably find that your code is either subject to NullReferenceExceptions, or forcing implementors to supply loggers as arguments. Use the null object pattern to avoid both these problems. This article teaches you how in C#. Null object might be confusing for some people because it seems to imply that the object reference might be null. However, the opposite is true. The object will never be a null reference. Null refers to the behavior of the object - not the reference itself. I think that a better name for the pattern would be Dummy Object Pattern since the objects you will use are shells with no behavior.  Why Use the Null Object Pattern? If you inject dependencies into your classes, you need to validate against null or perform null checking throughout your code. The null conditional operator ?. helps, but it is still very easy to miss one. Every single missed question mark is a bug in the code. The null object pattern gives you a third option of using a dummy object instead. This reduces the number of code paths and therefore decreases the chance of NullReferenceExceptions while still allowing the implementor to instantiate the class without creating an instance of the dependency. In the case of ILogger, it is quite onerous to create an implementation. Simply put, you shouldn't do it. If you want to implement logging, you should use an existing logging library. It becomes even more onerous if the dependency is ILoggerFactory. The implementor needs to pull in external dependencies or create a cascading set of classes that they may have no idea how to implement. It gets much worse when you try to mock ILogger or ILoggerFactory dependencies. Although it is still important to verify that logging gets called. You can read about that here.  The Basics The good news is that the Microsoft.Extensions.Logging.Abstractions namespace comes with null objects right out of the box. All you need to do is use NullLogger.Instance and NullLoggerFactory.Instance as default instances in your constructor. That's it. Your class can now depend on these instances, as though there is a real instance.  This example guarantees that the logger will never be null without forcing the code to supply a logger. The readonly modifier ensures that the instance cannot be set to null after construction. The code does not throw a NullReferenceException: using Microsoft.Extensions.Logging; using Microsoft.Extensions.Logging.Abstractions; using System; namespace ConsoleApp { class Program { static void Main(string[] args) { new Example().Print(Hello World!); } } public class Example { readonly ILogger _logger; public Example(ILogger logger = null) { _logger = logger ?? NullLogger.Instance; } public void Print(string message) { _logger.LogTrace(Logged message: {message}, message); Console.WriteLine(message); } } } In some cases, your class should take an ILoggerFactory instance because it may need to pass loggers to child dependencies in the future. You can use the same approach. namespace ConsoleApp { class Program { static void Main(string[] args) { new Example().Print(Hello World!); } } public class Example { readonly ILogger _logger; readonly ILoggerFactory _loggerFactory; public Example(ILoggerFactory loggerFactory = null) { _loggerFactory = loggerFactory ?? NullLoggerFactory.Instance; _logger = _loggerFactory.CreateLogger<Example>(); } public void Print(string message) { _logger.LogTrace(Logged message: {message}, message); Console.WriteLine(message); } } } Notice that we use the static property instance of both classes. We could create new instances of these objects in each case, but this would consume extra memory CPU to construct. The static instances only instantiate once i...