Roundup #39: Performance Tricks, Orleans Dashboard, ASP.NET Tips, Six Little Lines of Fail

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Some performance tricks with .NET strings

I’ve created a pull request on the ASP.NET Core repository. At the beginning, the changes were just about changing the unsafe code (char*) for stackalloc to a safe version with Span<T>. So, it was a very small change. During the review, Oleksandr KolomiietsGünther Foidl, and David Fowler have suggested a few additional changes to improve the performance. Thank you very much for taking the time to review the PR! The comments were very interesting, so I’ve decided to explain them in a post.

Link: https://www.meziantou.net/2019/03/04/some-performance-tricks-with-net-strings

Microsoft Orleans   Dashboard

Quick update to a post I did a while back regarding Orleans Dashboard — additional reporting metrics for your cluster!

As a refresher, Orleans is a virtual actor model framework — a framework that can be used to build new, distributed “primitives”. These primitives’ work can be farmed out to a cluster of nodes as a means of getting “work” done faster than what would be possible if working constrained to a single piece of hardware.

Link: https://hackernoon.com/microsoft-orleans-dashboard-update-cpu-memory-stats-706daed82cf8

Tips and tricks for ASP.NET Core applications

This is a small collection of some tips and tricks which I keep repeating myself in every ASP.NET Core application. There’s nothing ground breaking in this list, but some general advice and minor tricks which I have picked up over the course of several real world applications.

Link: https://dusted.codes/advanced-tips-and-tricks-for-aspnet-core-applications

Six Little Lines of Fail – Jimmy Bogard

It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code! Finally we can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code.

But those lines hid a dark secret that we only found after launching. Customers complained they didn’t get their email. The back end system wasn’t getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged!

Clearly it wasn’t as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we’ll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We’ll also look at the coupling our code contains, and the ways we can address it. Finally, we’ll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing.

Link: https://www.youtube.com/watch?v=LGG3IIHUG_w

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #38: Port Desktop App to .NET Core 3, Building 300+ csproj, .NET Core 3 Progress, Four Languages from Forty Years Ago

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

How to port desktop applications to .NET Core 3.0

In this post, I will describe how to port a desktop application from .NET Framework to .NET Core. I picked a WinForms application as an example. Steps for WPF application are similar and I’ll describe what needs to be done different for WPF as we go. I will also show how you can keep using the WinForms designer in Visual Studio even though it is under development and is not yet available for .NET Core projects.

Link: https://devblogs.microsoft.com/dotnet/how-to-port-desktop-applications-to-net-core-3-0/

How do you all build really large .NET repos (like more than 300 .csproj)?

This is a really interesting thread. I can’t imagine building 300+ projects. I currently have a solution with just around 50 and I’m always trying to reduce it. What type of projects are people working that require 300+ projects?

Link: https://twitter.com/natemcmaster/status/1099021447920406529

.NET Core 3.0 Progress on Bugs

Link: https://twitter.com/ziki_cz/status/1100865306484850688

Four Languages from Forty Years Ago – Scott Wlaschin

The 1970’s were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?

In this talk, we’ll look at four languages designed over forty years ago — SQL, Prolog, ML, and Smalltalk — and discuss their philosophy and approach to programming, which is very different from most popular languages today.

We’ll come away with some practical principles that are still very applicable to modern development. And you might discover your new favorite programming paradigm!

Link: https://www.youtube.com/watch?v=0fpDlAEQio4

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Is CQRS Complicated?

There are many misconceptions about CQRS. It’s often referenced alongside other patterns that can make it seem difficult and complicated. Is CQRS complicated? No. CQRS is simple. Really simple.

What is CQRS?

First, let’s tackle at the very core what CQRS actually is.

CQRS stands for Command Query Responsibility Segregation and was coined by Greg Young. CQRS is related to CQS (Command Query Separation) principle by Bertrand Myer which states:

Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

In other words, a command is a method that mutates state and query is a method that returns state. A method generally doesn’t do both, but there are exceptions to this rule.

CQRS takes CQS a step further by separating commands and queries into different objects.

To use an exampling in C#, here is a shipment class has two methods. It applies CQS, in that each method either performs an action or returns data.

CQRS Applied

If we take the above class and were to apply CQRS, we simply just need to turn this into two objects. One object would be used for mutating state (ShipmentCommand) and the other object for returning state (ShipmentQuery).

That’s it. You’ve just applied CQRS. Wasn’t that totally unexciting?

Misconceptions

I suspect the reason for the misconceptions about being complex and difficult stems from people seeing a diagram like this:

Is CQRS Complicated?

If you search google images for CQRS, you are bound to find almost every diagram that looks like the one above or some variation of it.

Is the diagram applying CQRS? Yes.
Is the diagram only applying CQRS? No.

When you hear talks or read about CQRS you are often also hearing about a bunch of other patterns or technology. Mainly those that in attempted to be represented in the diagram above.

You do not need:

  • Message Broker or Bus
  • Messaging
  • Domain Model
  • Domain Events
  • Event Sourcing
  • Eventual Consistency
  • Separate Models for Reads and Writes
  • Domain Driven Design

Enabler

I often say that CQRS is an enabler. It enables or facilitates using other patterns that often fit well together. This is why you often see CQRS and Event Sourcing applied together.

CQRS is not Event Sourcing nor does it require you to use Event Sourcing. CQRS simply fits well and enables you to apply Event Sourcing.

Fat Controller CQRS Diet

I’ve blogged a bit about how to implement CQRS without any of the other fluff. You can check out my Fat Controller CQRS Diet blog series as well as a related talk:

More

I plan on breaking down some of the misconceptions and other aspects that are often lumped in with CQRS in coming posts.

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.