My F# Journey – F# Learning Resources

F# CloudThinking about learning functional programming with F#?  Here is a list of F# learning resources that will help you on your own F# journey.

Robert C. Martin – Functional Programming: What? Why? When?

Why is functional programming becoming such a hot topic? Just what is functional programming anyway? And when am I going to have to know about it? In this talk Uncle Bob will walk you through the rationale that is driving the current push towards functional programming. He’ll also introduce you to the basics by walking through some simple Clojure code.

F# Software Foundation

http://fsharp.org/

A wealth of information.  There are some very useful walkthrus on how to use F# on various platforms (Windows, Linux, Mac).  As well, there are many guides on how to use F# for Web Programming, Mobile, Cloud, Financial, etc.

Try F#

http://www.tryfsharp.org/

There is an interactive window that allows you to write and execute F# directly in your browser.  This is nice if you want to experiement with F# without having installing F# or an IDE.

F# for fun and profit

http://fsharpforfunandprofit.com/

I found this site very approachable coming from an enterprise and line of business development background.  I found it to be an easier read than most.

Domain Driven Design, Event Sourcing and CQRS with F#

Ever since I discovered the “blue book” by Eric Evans, I’ve been immersed in Domain Driven Design, Event Sourcing, CQRS, and Messaging.  If you are familiar with these concepts than this talk by Lev Gorodinski is worth a watch.

 

ToDo-Backend

https://github.com/panesofglass/TodoBackendFSharp

When you are ready to jump into some real code take a look at the Todo MVC app written in F#.

More…

If you have any suggestions, please comment and let me know which sites/resources you have found helpful.

My F# Journey – What I’ve learned so far

fsharpThis is a first blog post in a series to document my experiences while learning functional programming. This is my F# Journey.

During my 15 year career that started in the late 90’s, I have not made very many conscious decisions about learning a specific language or technology.  The path I’ve taken and the experience I’ve gained seems like it just happened naturally.

As someone always wanting to learn, I usually find some interesting topics and start going down the rabbit hole (Domain Driven Design, CQRS, Event Sourcing… thanks Greg Young), however I never usually set out on a “I’m going to learn X” journey.

That’s about to change.

As with anyone that keeps up with the latest trends, functional programming is all the rage.  And I do believe for good reason (more on that later),  which is why I’ve decided to take on the journey of learning with F#.   I’ve chosen F# because of my .NET/C# background and feel it can help my career to keep it in the .NET ecosystem.

What I’ve learned so far…

Stop comparing it to C#

apple-vs-orange

It’s natural when looking at another imperative language that you are unfamiliar with, to compare it to the language you know best.   The concepts are all transferable.  How do I perform a loop?  How do I define a variable?  How do I assign a variable?

With a quick search and reading a few examples,  you are off to the races writing some basic code in a new imperative language.  Stop trying to compare concepts.

Let it go!

Open up your mind to new ideas and try and forget everything you know.

Think like a beginner.

Just because you can, doesn’t mean you should

Because F# is a hybrid language and supports some of the concepts of an imperative language, doesn’t mean you should use them.  In pure functional languages, there are no loops or objects.

Let it go!

Just because you can use F# in a non-functional way, doesn’t mean you should (especially while learning).

When reading intro articles, you will see the following statements over and over again: “start thinking functionally” or “start thinking differently”.  It’s hard at first to really grasp what this really means.  Once you finally let go of the imperative way of thinking, you will get an “AH HA!” moment.

Read & Play

Anytime I’ve ever learned a new language it has always been through practical use in a small app.  However, I do find that learning the basics of F#, understanding F# types, and thinking like a beginner before jumping into real code has been helpful.  I’m using Visual Studio and writing code, but more as a playground than attempting actually write an app.  Once I feel comfortable enough and actually feel like I fully “get it”, I’m going to start writing a simple app.

Query Objects with a Mediator

Mediator

In my previous blog Query Objects instead of Repositories, I demonstrated creating query objects and handlers to encapsulate and execute query logic instead of polluting a repository with both read and write methods.  Since we have moved away from repositories and are now using query objects, we will introduce the Mediator pattern. It will allows have a common interface that can be injected into our controller or various parts of our application. The mediator will delegate our query objects to the appropriate handler that will perform the query and return the results.

First we will create an interface that will be used on all of our query objects.

public interface IQuery<out TResponse> { }

Now we need to create an interface that all of our query handlers will implement.

public interface IHandleQueries<in TQuery, out TResponse>
	where TQuery : IQuery<TResponse>
{
	TResponse Handle(TQuery query);
}

Next we will create our Mediator interface. Most examples you will see that are implementing command handlers generally are showing an IFakeBus or something similar. The difference being that generally in the Bus implementation there is no return type. On the query side, our intent is to return data.

public interface IMediate
{
	TResponse Request<TResponse>(IQuery<TResponse> query);
}

There are many ways you can implement your mediator. As an example:

public class Mediator : IMediate
{
	public delegate object Creator(Mediator container);

	private readonly Dictionary<Type, Creator> _typeToCreator = new Dictionary<Type, Creator>();

	public void Register<T>(Creator creator)
	{
		_typeToCreator.Add(typeof(T), creator);
	}

	private T Create<T>()
	{
		return (T)_typeToCreator[typeof(T)](this);
	}

	public TResponse Request<TResponse>(IQuery<TResponse> query)
	{
		var handler = Create<IHandleQueries<IQuery<TResponse>, TResponse>>();
		return handler.Handle(query);
	}
 }

Now that we have our interfaces and mediator implementation, we need to modify our existing queries and handlers.

public class ProductDetailsQuery : IQuery<ProductDetailModel>
{
	public Guid ProductId { get; private set; }

	public ProductDetailsQuery(Guid productId)
	{
		ProductId = productId;
	}
}

public class ProductDetailQueryHandler : IHandleQueries<ProductDetailsQuery, ProductDetailModel>
{
	private DbContext _db;
 
	public ProductDetailQueryHandler(DbContext db)
	{
		_db = db;
	}
 
	public ProductDetailModel Handle(ProductDetailsQuery query)
	{
		var product = (from p in _db.Products where p.ProductId == query.ProductId).SingleOrDefault();
		if (product == null) {
			throw new InvalidOperationException("Product does not exist.");
		}
 
 		var relatedProducts = (from p in _db.RecommendedProducts where p.PrimaryProductId == query.ProductId);
 
 		return new ProductDetailsModel
		{
			Id = product.Id,
			Name = product.Name,
			Price = product.Price,
			PriceFormatted = product.Price.ToString("C"),
			RecommendedProducts = (from x in relatedProducts select new ProductDetailModel.RecommendedProducts {
				ProductId = x.RecommendedProductId,
				Name = x.Name,
				Price = x.Price,
				PriceFormatted = x.Price.ToString("C")
			})
		};
	}
 }

Now in our controller, instead of either creating a new instance of the query handler in our controllers or having all them injected into the constructor, we now simply inject the mediator.

public class ProductController : Controller
{
	private IMediate _mediator;
	
	public ProductController(IMediate mediator)
	{
		_mediator = mediator;
	}
	
	public ViewResult ProductDetails(ProductDetailQuery query)
	{
		var model = _mediator.Request(query);
		return View(model);
	}
}

As before, we have encapsulated the generation of our view model into its own object but now a common interface in a mediator to handle the incoming query object requests.