.NET / WPF

Reactive Extensions, ReactiveUI, and Whistling Tea Kettles

How does reactive programming work? “It’s all streams,” our program manager explained. “When you update a property in one part of the system, it causes another property in a different part of the system to update, too. It will take a bit to wrap your mind around.”

In my head, I pictured properties all over the system “magically” updating when a user clicks a button. Due to the lack of magic in programming, this mental image was not a complete picture—but it’s not that different from how reactive programming actually works.
Read more on Reactive Extensions, ReactiveUI, and Whistling Tea Kettles…

DRYing Up Shared Web.config Settings

I recently modified some connection strings and settings across multiple ASP.NET web applications in a large solution. It (only) took an hour, but in the process I found multiple incorrect and stale settings. The code violated the DRY principle. The fix involved referencing the common shared settings from a single source instead of repeating them across the solution. Read more on DRYing Up Shared Web.config Settings…

A Feature-Oriented Directory Structure For C# Projects

After working on .NET applications for the past six years, I recently spent a few months using Ember.js and AngularJS. Both originally supported organizing files in a project by type: separate top-level directories for models, controllers, views, etc. But this has changed over the past few years to prefer organizing by feature area—Ember with pods Angular with modules.

It’s worked well for Javascript apps, so I recently experimented by converting one of my C# apps to follow the same principles. Read more on A Feature-Oriented Directory Structure For C# Projects…

Using a Design-Time ViewModelLocator With Caliburn.Micro

I was introduced to Caliburn.Micro less than a year ago, and it has since become my preferred MVVM framework for XAML development. It supports several conventions that reduce boilerplate code. It’s an opinionated framework that encourages a ViewModel-First approach during development.

Unfortunately, design-time support out of the box is limited to ViewModels with a public parameterless constructor1. This works for a while, but it becomes tedious to duplicate and maintain code that only exists for design-time support. I now use a DesignTimeViewModelLocator class for binding sample data in the designer. Read more on Using a Design-Time ViewModelLocator With Caliburn.Micro…

Functional C# Application Composition, Part 3: MethodToDelegate

In part 2 of this series I made a case that switching from Stateless Single-Responsibility Objects to delegates and static methods lets us write simple, pure functions and lets us remove a lot of boilerplate.

Nevertheless, there was still one bit of boilerplate I hadn’t yet removed. It dealt with encapsulating dependencies to a method in order to match a delegate signature for use in other parts of the application. Read more on Functional C# Application Composition, Part 3: MethodToDelegate…