Development With A Dot

This will be the third post on OData and ASP.NET Core 3. Please find the first post (basics) here and the second post (querying) here. This time, I will talk about actions and functions. For demo purposes, let’s consider this domain model:

Update: see the third post here.

Update: see the second post here.

It has always been possible (but a tad problematic) to submit dynamic contents to an ASP.NET Core controller action. In the dark, pre-Core days, we had to implement a custom model binder for this. Now it is no longer the case.

When it comes to unit testing, it is common to use mocking to replace “external” services, that is, those that are not part of the subject under test. Not everything can be mocked, and, sometimes, when we instantiate non-POCO classes, such as controllers (ControllerBase), there are lots of things that are not instantiated by the framework and are left for us do to. Just think, for example, if you want to access request or quest string data or know if the user is logged in?

ASP.NET Core 3 introduced a not so talked about feature which is dynamic routing. In a nutshell, it means that it is possible to decide at runtime the controller, action and route tokens that a request will be dispatched to. The idea is to map a route pattern to a dynamic route handler, like this:

This is my fourth post on performance in the .NET world. See the first one on object instantiation here and the second on property copying here and the third here. This time I’m going to talk about collections, but focusing on the performance side.This time, I’ll be talking about value types.