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…

Functional C# Application Composition, Part 2: Delegates

In my previous post on the Stateless Single-Responsibility Object (SSRO) approach to C# application composition I reviewed the concept and its shortcomings.

To recap:

  1. You end up with a ton of classes splitting up semi-related logic across multiple files. This is necessary to conform to the classname == filename convention.

Read more on Functional C# Application Composition, Part 2: Delegates…

Functional C# Application Composition, Part 1: Shortcomings of Single-Responsibility Objects

Functional code is easier to test than code with state or side effects. However, most developers spend the majority of their time in traditional, imperative languages. There’s plenty of value in those imperative languages, but these days when I use one, I also try to bring in applicable functional concepts.

In this post I will explore how a stateful, Object-Oriented approach to composition became painful to me, and in my next post I will discuss my proposed functional solution. Read more on Functional C# Application Composition, Part 1: Shortcomings of Single-Responsibility Objects…