Roundup #57: Dapr, .NET Core API Porting, EF Core 3 NETStandard2, ASP.NET Core Best Practices

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Announcing Distributed Application Runtime (Dapr)

Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge. Dapr embraces the diversity of all programming languages and developer frameworks and simplifies building applications such as the e-commerce example.

Link: https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-dapr-open-source-project-build-microservice-applications/

.NET Core 3.0 concludes the .NET Framework API porting project

We started in .NET Core 1.0 with a very minimal API set that only included ~18K of the .NET Framework APIs. With .NET Standard 2.0, we tried to make it much more viable to share code between .NET Framework, .NET Core, and Xamarin which resulted in approximately 38K .NET Frameworks APIs being available in .NET Core 2.0. We also built the Windows Compatibility Pack which made another 21K .NET Framework APIs available to .NET Core, resulting in almost 60K additional APIs. And in .NET Core 3.0 we added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs.

Link: https://github.com/dotnet/announcements/issues/130

EF Core 3 to target .NET Standard 2.0

The feedback from you and others is that EF Core made the jump to .NET Standard 2.1 too soon. A lot of apps are still transitioning to .NET Core, and the ecosystem of libraries (especially WinForms and WPF) is also still translationing. Even UWP and Unity aren’t ready for .NET Standard 2.1 yet.

After investigating this, we discovered that a lot more of corefx has been backported to .NET Standard 2.0 than we originally anticipated when we made the decision to target .NET Standard 2.1.

Given your feedback and the unexpectedly low cost of maintenance–remember, we’re just a small team of five engineers–we decided it was probably worth implement this.

We hope that one last LTS release on .NET Standard 2.0 will give everyone a chance to catch up to the vision of .NET 5.

Link: https://github.com/aspnet/EntityFrameworkCore/issues/18141#issuecomment-542798580

ASP.NET Core Performance Best Practices

I never noticed this portion of the docs and found it really interesting to see some best practices, particularly around the performance reliability. I really like the DO vs DO NOT examples.

Link: https://docs.microsoft.com/en-us/aspnet/core/performance/performance-best-practices?view=aspnetcore-3.0#performance-and-reliability

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #56: Blazor Server Performance, NetCore3 as Self-Contained, F# and Giraffe, Domain Modeling Made Functional

.NET Roundup

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Blazor Server in .NET Core 3.0 scenarios and performance

Since the release of Blazor Server with .NET Core 3.0 last month lots of folks have shared their excitement with us about being able to build client-side web UI with just .NET and C#. At the same time, we’ve also heard lots of questions about what Blazor Server is, how it relates to Blazor WebAssembly, and what scenarios Blazor Server is best suited for. Should you choose Blazor Server for your client-side web UI needs, or wait for Blazor WebAssembly? This post seeks to answer these questions, and to provide insights into how Blazor Server performs at scale and how we envision Blazor evolving in the future.

Link: https://devblogs.microsoft.com/aspnet/blazor-server-in-net-core-3-0-scenarios-and-performance/

Deploying .NET Core 3 apps as self-contained

Link: https://timheuer.com/blog/archive/2019/10/03/deploy-aspnet-core-applications-using-self-contained-dotnet-core.aspx

Yay! .NET Core 3.0 is now available!  You now are migrating your apps and want to get it to your favorite cloud hosting solution.  But they may not have it quite ready yet and you are still eager to deploy to production.  No worries, we have a solution for you.

F# and Giraffe with Stuart Lang

In this episode I interviewed Stuart about F#, Giraffe, the SAFE stack, and whether you should contemplate using a functional paradigm for web development. Some of you may know Stuart from his work on his website at stu.dev, or the events DDD southwest.comF# Bristol and .NET Southwest – all of which he helps to run.

Link: https://dotnetcore.show/episode-34-f-and-giraffe-with-stuart-lang/

Scott Wlaschin – Talk Session: Domain Modeling Made Functional

Statically typed functional programming languages encourage a very different way of thinking about types. The type system is your friend, not an annoyance, and can be used in many ways that might not be familiar to OO programmers.

Types can be used to represent the domain in a fine-grained, self documenting way. And in many cases, types can even be used to encode business rules so that you literally cannot create incorrect code. You can then use the static type checking almost as an instant unit test — making sure that your code is correct at compile time.

In this talk, we’ll look at some of the ways you can use types as part of a domain driven design process, with some simple real world examples. No jargon, no maths, and no prior FP experience necessary.

Link: https://www.youtube.com/watch?v=PLFl95c-IiU

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Avoiding the Repository Pattern with an ORM

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pitfalls that I’ve seen.

To clarify, since this topic seems to really fire people up, I’m not saying that you shouldn’t use the repository pattern. I’m going to clarify why I don’t think under certain situations it’s very useful and other situations that I do find it useful.

This post was spurred on by a blog post and tweet:

IQueryable

The first thing I’ve seen with a repository is exposing IQueryable<T> (or DbSet<T>) from the underlying DbContext in your repository. This serves no purpose. It’s not abstracting anything at all.

What’s even worst is the consumers/callers don’t necessarily know at what point will they actually be retrieving data (doing I/O), unless you’re aware that the underlying IQueryable is coming from Entity Framework., Now when you call a method that materializes your query and actually hits the database (such as ToListAsync()).

Lazy Loading

Second, to this point is now if you have any type of navigation properties and are accessing IQueryable<T> from repository consumers, you must either eager load (via Include()) or have your consumers do the Include() or not realize all navigation properties are lazy loading.

Again, consumers are now aware of the underlying implementation that is Entity Framework.

IEnumerable

To overcome these issues, usually what comes next is avoiding the IQueryable<T> by returning an IEnumerable<T>.

The issue now is since you’re taking away control from the consumer, you must decide what data to Include() and Select() behind query methods.

What this often turns into is a pile of methods with various filtering parameters that could have been much easier expressed via a LINQ expression against the DbSet directly.

Query Objects

So if I don’t generally use the repository pattern, what do I use? Query Objects.

For querying, I’d rather have specialized objects that can return very specific data for the given use case. When implementing in vertical feature slices, as opposed to layers, each query is responsible for how it retrieves data.

The simplest solution is to use the DbContext and query directly.

The primary benefit is query objects only have dependencies that they actually require. Because each query object defines its own dependencies, you can change those dependencies without affecting other query objects.

A simple example of this is if you wanted to migrate from Entity Framework 6 to Entity Framework Core. You could migrate one query object at a time to EF Core instead of having to change over an entire repository that is highly coupled.

Testing

I can see the argument for using a repository because testing was difficult with EF6. However, with EF Core using the SQLite or the InMemory Provider, testing is incredibly easy.

I’ve written a post on how to use the SQLite provider with an in-memory database.

Testing a Query Object becomes incredibly easy without the need to mock.

Caching

Another argument for using the repository pattern is being able to swap out the implementation for a “cached repository”. I do use this pattern but in very select cases. Most times this is across bounded context were cached or stale data is acceptable.

If you decide to swap out the implementation of your repository, which was previously always hitting the database (point of truth) and now is using a cache implementation, how does that affect the callers? How quickly is the data invalidated?

Data can be stale the moment you retrieve it from the database, however adding caching to your repository without your callers knowing it can have a big impact on behavior.

Aggregate Root

One place I do often use a repository is when accessing an aggregate (in DDD Terms). My repositories often only contain two methods, Get(id) and Save(aggregateRoot).

The reason I do use a repository in this situation is that my repository usually returns an object that encapsulates my EF data model. I want it to fetch the entire object model and construct the aggregate root. The aggregate root does not expose data but only behavior (methods) to change state.

Repository Pattern Related

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.