<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>.NET on On The Drift</title><link>https://www.onthedrift.com/tags/.net/</link><description>Recent content in .NET on On The Drift</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><managingEditor>koen@linker.io (Koen)</managingEditor><webMaster>koen@linker.io (Koen)</webMaster><lastBuildDate>Thu, 15 Jul 2021 00:00:00 +0000</lastBuildDate><atom:link href="https://www.onthedrift.com/tags/.net/index.xml" rel="self" type="application/rss+xml"/><item><title>EFCore.Projectables and the curious case of an unexpected performance boost</title><link>https://www.onthedrift.com/posts/efcore-projectables-perf/</link><pubDate>Thu, 15 Jul 2021 00:00:00 +0000</pubDate><author>koen@linker.io (Koen)</author><guid>https://www.onthedrift.com/posts/efcore-projectables-perf/</guid><description>Last time, I wrote about a new library called EntityFrameworkCore.Projectables. In short this library allows us to query over properties and methods completely written in CSharp. While I was implementing benchmarks to test the overhead of this Library, I was surprised to find out that the performance was actually improved when using Projectables over not using Projectables. Surely I must have made a mistake somewhere right? Well, lets dive in and see if we can find that out!</description></item><item><title>EF Projections on computed properties and methods without a hassle!</title><link>https://www.onthedrift.com/posts/efcore-projectables/</link><pubDate>Thu, 03 Jun 2021 00:00:00 +0000</pubDate><author>koen@linker.io (Koen)</author><guid>https://www.onthedrift.com/posts/efcore-projectables/</guid><description>One of EF&amp;rsquo;s main selling points is that it allows you to write queries without having to deal with the underlying database technology being used. This however has its limitations as you as a developer will have likely encountered. EFCore is only able to handle expressions that are typed as such. As a result, if you try to select anything from a locally computed property or method then EFCore will have to fall back to client-side evaluation to compute the result of that expression which may be inefficient and is certainly limiting!</description></item><item><title>Introducing ScenarioTests, an experiment in improving the .NET testing experience</title><link>https://www.onthedrift.com/posts/scenario-tests/</link><pubDate>Mon, 03 May 2021 00:00:00 +0000</pubDate><author>koen@linker.io (Koen)</author><guid>https://www.onthedrift.com/posts/scenario-tests/</guid><description>&lt;p>When developing software, you&amp;rsquo;ll sooner or later be confronted with the notion of Tests. In the .NET landscape we have plenty of &lt;a href="https://docs.microsoft.com/en-us/dotnet/core/testing/">tools&lt;/a> at our disposal to help us test our code. In this post I&amp;rsquo;d like to introduce &lt;a href="https://github.com/koenbeuk/ScenarioTests">ScenarioTests&lt;/a>. A new project that aims to make testing in .NET better.&lt;/p></description></item><item><title>Triggers for Entity Framework Core</title><link>https://www.onthedrift.com/posts/efcore-triggered-part1/</link><pubDate>Fri, 23 Apr 2021 00:00:00 +0000</pubDate><author>koen@linker.io (Koen)</author><guid>https://www.onthedrift.com/posts/efcore-triggered-part1/</guid><description>When our codebase grows, so does its complexity. One way of managing this growing complexity is by leveraging triggers. Essentially this means that we’re able to run arbitrary code whenever a database commit occurs. Luckily for us, EF Core already provides the necessary infrastructure to embrace triggers. All we need to add is a bit of plumbing. EntityFrameworkCore.Triggered is a NuGet package that does just that. The source can be found over on Github.</description></item><item><title>Activator utilities: activate anything!</title><link>https://www.onthedrift.com/posts/activator-utilities/</link><pubDate>Thu, 22 Apr 2021 00:00:00 +0000</pubDate><author>koen@linker.io (Koen)</author><guid>https://www.onthedrift.com/posts/activator-utilities/</guid><description>&lt;p>Dependency injection (DI) is a well-known technique that helps in writing more maintainable code. .NET has excellent support for Dependency injection and is heavily used in platforms such as ASP.NET Core. However, did you know there is a way to automatically instantiate a type with constructor arguments provided from an IServiceProvider without having to register that type with the DI Container first? That&amp;rsquo;s where &lt;a href="https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.activatorutilities?view=dotnet-plat-ext-5.0">ActivatorUtilities&lt;/a> comes in.&lt;/p></description></item></channel></rss>