I gave .net core a chance ... And returned for more Laravel

03 June 2019 | Laravel, PHP, C#

Professionally, I work as a consultant .Net developer. "Why?" you might ask? The PHP market in Belgium is very small, .net dominates the market and there are only a hand full of small PHP development companies within a one hour drive of where I live. The reason for this escapes me as every company I work at swears at every change Microsoft makes to its framework, but that's a discussion for another time.

On the other hand, I also do a lot of programming as a hobby. All of these projects are made using PHP and almost always in combination with the Laravel framework. This astonishes people both the professional world as friends of mine who are programmers.

Going .net core all the way#

Since a few months, I have been working on a plan to optimize my website, TableTopFinder. I was going to build the project from the ground up starting with a clean slate. So, since .net core had been made open source, and it runs great on Linux, and it would be a great way to grow in my professional career, I thought I'd give it a chance.

Problem 1: Querying the database#

In the .net world, there are a hand full of supported packages that can be used to query the database.

Entity Framework

The first one I looked at was the most used one: Entity Framework. This is probably the most used ORM package for .net, mainly because of how simple it is to use. Once set up, you can easily query your objects like follows and Entity Framework will take care of connecting to the database and building the query:

var posts = context.BlogPosts
	.Where(post => post.published)
	.OrderBy(post => post.publishDate)

This works amazingly well! ... Until you start using complicated queries and relations. For starters, the functions for relations are very limited, you cannot filter relations, nor limit the number of fields that get returned. Also, some of the queries generated by Entity Framework are monstrosities: subquery in subquery in subquery ...

I know that this can be optimized by configuring relations and indexes correctly, but it is so complicated and badly documented that I gave up. The fact that it is so hard to control the anatomy of the SQL query is what eventually ended my tests with Entity Framework.


Next on the list was Dapper. This library takes a whole other approach by letting you write the SQL query yourself, but it takes care of the database connection and mapping of the objects. This sounded great to me because now I could control the SQL queries actually look like!

After a while though, I started to get some annoyances with this library. Mainly because you had to reuse a lot of boilerplate query parts. For example, my database scheme contains one translations table for all entities. But because Dapper has no concept of reusability I have to write this query over and over again for each of the entities.

I have tried to get around this using inheritance and merging strings. But this completely destroyed the parameterized nature of Dapper and made the project possibly vulnerable for query injections. So after a few days of testing, I decided to not use this way of working.

Creating my own ORM

Crazy as it seems, I did actually start a brand new project with an Laravel-query-builder-like API. However, it soon became clear to me how complex it is to build something like this and I stopped working on this a few hours in. I would have found it amazing to create this, but I do not have the time to maintain a project on this scale.

Also, there are several projects that have already attempted this (such as SqlKata), but they were either incomplete or dead projects.

Problem 2: Authentication#

For my new project, I wanted to use one central authentication application that manages authentication for all projects and API's. Luckily there is open-source one project in the .Net world that bundles all that: Identity Server.

This is the part where I discovered .net developers hate documentation; Yes, Identity Server has extensive documentation, but all of it uses the same configuration, in memory resources. In practice, nobody will hardcode users, clients and other entities in their authentication server. However, there is no documentation on how to load external data sources.

"But Jeroen, there is documentation on how to implement Entity Framework". Indeed there is, but I don't want to use Entity Framework. Eventually, though, I found out how to use my own repository classes to load data from the database, but I had to find this on page 6 of a Google search.

Even after this, combining Identity Server with the build in Identity provider from .Net core is a pain in the neck. The .Net API is constantly changing which makes it so that there are several functions to configure the identity provider and each works in its own way. Luckily, by this time, I switched from Visual Studio to Rider, which allowed me to debug through packaged dll's. If not for this, I probably would have given up trying to implement Identity Server.

To be honest, this is not a rant on authentication or Identity Server, but for documentation on .net core and its packages. Some don't even bother to document their packages because "Intellisense will show you how to use it". I was really annoyed how bad the documentation for everything is in comparison with packages written in PHP or javascript or any other language.

Back to Laravel#

After tinkering for several weeks on a proof of concept project for the authentication, I was not able to create a working prototype. To make sure I wasn't misusing concepts, I decided to make the exact same project using Laravel Passport and see if it had the same problems. And guess what: after no more than two days, I had a working authentication server that allowed me to register clients and users, had out of the box email verification and password reset functionality and a great user interface.

This was the moment I realized I had to stick with Laravel. I knew these two problems I had wouldn't be the last ones and programming as hobby should be fun and not tedious.

To conclude#

Let it be clear that I do not hate .Net at all. In fact, I think C# is an amazing programming language that has some features PHP could still learn from. The problem is the .Net framework that is built around this language is really complicating things, mostly due to the fact that the API constantly changes and the documentation stays behind.

I really like my job and for now, I will remain a .Net developer professionally. However, if given the choice, I strongly prefer Laravel & PHP which is a great combination to create web applications.

Closing thoughts

Wow, I never expected this post to be this long, sorry for the long rant. I even cut out a few parts because this would get too lengthy. Hopefully, you enjoyed this post, feel free to send me a comment if you agree or disagree with what I wrote.

Jeroen Deviaene
I am a full-stack web developer from West-Flanders who enjoys creating applications and websites using frameworks such as Laravel, VueJs and Tailwind CSS.
Looking for a Laravel developer?
Contact me