Applying Functional Principles in C# Pluralsight course

By Vladimir Khorikov

My new course Applying Functional Principles in C# for Pluralsight went live.

Applying Functional Principles in C#

What interesting about functional programming is that it allows you to adhere to the most important software development principles, just as the DDD practices do. It helps reduce the cognitive load when you deal with your code base and thus keep your software maintainable in a long term.

This course is based on the article series I posted awhile back. The course goes into the topic much deeper, however. It covers such themes as:

  • The fundamental principles that lie at the foundation of functional programming.
  • Immutable architecture and how to handle side effects which cannot be eliminated entirely.
  • Why the use of exceptions for controlling the program flow contradicts functional principles and how to refactor away from that practice.
  • Getting rid of primitive obsession.
  • Why nulls are evil and how to mitigate the billion dollar mistake.
  • Applying the Railway Oriented Programming approach in C# for handling failures and input errors.

The course doesn’t touch such topics as LINQ, extension methods, lambdas and higher-order functions. I deliberately didn’t include them because there’s enough such information on the Internet already. Instead, I wanted to talk about fundamental functional programming principles. They are quite simple but you would be surprised how many useful but lesser-known techniques flow from them.

The last part the course goes through refactoring of a fairly complex project with a functionality typical for a line of business application. You will see, step by step, how to apply all techniques described in the course in practice: how to deal with nulls, get rid of primitive obsession, eliminate as much side effects as possible, handle validation errors and failures, and more.

The sample project is built using Visual Studio 2015, C# 6, SQL Server, NHibernate and ASP.NET Web API. The code from the course is the code I use in production systems on a daily basis, so you can safely employ it in your own projects.

You can watch the course here: link.

I have some trial codes for this course too, so if you want to watch it but don’t have a subscription, write me an email and I’ll send you one. With it, you’ll have an unlimited access to the Pluralsight library during 30 days.


  • Aleksey Bykov

    Nulls in general aren’t evil, _untracked_ nulls are. Some languages out there do track nulls and a million dollar mistake doesn’t bother anyone there. C# is just lagging way behind (although one step ahead of Java).

  • Jean Pierre Chauny

    Congratulations! The course is highly interesting. A must see for every c# programmer.

    • Vladimir Khorikov


  • Alexander Erygin

    This course is must have for .NET people!

  • Neil Newman

    Really enjoyed the course and have been looking at applying some of the concepts. One aspect that had me wondering is how to apply the railway style code when you have a disposable object.


    The using could be within an OnSuccess that does some work with the disposable object and then disposes it at the end, but that feels a bit removed from the creation of the disposable.

    We wrote:

    public static Result OnSuccessDispose(this Result result, Func<TDisposable, Result> func) where TDisposable : IDisposable
    if (result.IsFailure)
    return Result.Fail(result.Error);

    using (result.Value)
    return func(result.Value);

    it works quite nicely and is fairly Honest.

    The main issue is we feel the dispose is a bit far away from the create…

    Are there any better functional patterns for working with disposable objects?

    • Vladimir Khorikov

      That’s a great question. As a general rule, I would recommend not to expose disposable objects at all and compose the chain out of the methods that do the disposal internally. Here for example – – the email gateway creates an SMTP client internally and disposes of it after the work is done.

      The solution you proposed seems good enough, although I too don’t quite like the fact that the object is getting disposed of in the middle of the operation and not at the end of it. I don’t have a better alternative to it, only the advice to avoid exposing disposable things altogether.

      • Neil Newman

        Thanks, I think we will try not to use the using extension unless it really helps readability. This may be in the same class of problem as some of our DAL code where the “functional” code we want takes more than one parameter. I think I need to research Currying :-)