mickmelon.dev

Optimising Entity Framework with Projection-Friendly Mapping

2023-11-04T14:21:00+00:00

Introduction

Discovering more efficient ways to handle data queries can be quite enlightening. I recently had an “aha” moment with Entity Framework projections that I’d like to share, especially since it’s a pattern I’ve been using for quite some time.

The Initial Setup

I’ve set up an example ASP.NET Core Web API with the following entities:

public class CategoryEntity
{
    public int Id { get; set; }

    public string Name { get; set; } = null!;

    public string? Description { get; set; }

    public List<BookEntity> Books { get; set; } = null!;
}

public class AuthorEntity
{
    public int Id { get; set; }

    public string Name { get; set; } = null!;

    public string? Biography { get; set; }

    public string? Image { get; set; }

    public List<BookEntity> Books { get; set; } = null!;
}

public class BookEntity
{
    public int Id { get; set; }

    public string Name { get; set; } = null!;

    public string Blurb { get; set; } = null!;

    public string? Isbn { get; set; }

    public string? Publisher { get; set; }

    public DateTime? PublishedOn { get; set; }

    public decimal? Price { get; set; }

    public string? CoverImage { get; set; }

    public string? PreviewLink { get; set; }

    public string? PurchaseLink { get; set; }

    public string? AudibleLink { get; set; }

    public int AuthorId { get; set; }
    public AuthorEntity Author { get; set; } = null!;

    public int CategoryId { get; set; }
    public CategoryEntity Category { get; set; } = null!;
}

On projects I have worked on, to transfer data, we often create DTOs with MapFromEntity methods, which help maintain a clean separation of concerns:

public record AuthorDto
{
    public int Id { get; init; }

    public string Name { get; init; } = null!;

    public List<BookDto> Books { get; init; } = new();

    public static AuthorDto MapFromEntity(AuthorEntity entity)
    {
        return new()
        {
            Id = entity.Id,
            Name = entity.Name,
            Books = entity.Books.Select(BookDto.MapFromEntity).ToList()
        };
    }
}

public record BookDto
{
    public int Id { get; init; }

    public string Name { get; init; } = null!;

    public int CategoryId { get; init; }

    public string CategoryName { get; init; } = null!;

    public static BookDto MapFromEntity(BookEntity entity)
    {
        return new()
        {
            Id = entity.Id,
            Name = entity.Name,
            CategoryId = entity.CategoryId,
            CategoryName = entity.Category.Name,
        };
    }
}

These methods are then used in EF queries to fetch and map data:

List<AuthorDto> authors = await _dbContext.Authors
    .Include(_ => _.Books)
    .ThenInclude(_ => _.Category)
    .Select(_ => AuthorDto.MapFromEntity(_))
    .ToListAsync();

Have a look at the SQL query that was generated by EF. Note how this pulls out all the data from the relevant Authors, Books, and Categories tables, even though we’re only interested in a select few columns:

SELECT [a].[Id], [a].[Biography], [a].[Image], [a].[Name], [t].[Id], [t].[AudibleLink], [t].[AuthorId], [t].[Blurb], [t].[CategoryId], [t].[CoverImage], [t].[Isbn], [t].[Name], [t].[PreviewLink], [t].[Price], [t].[PublishedOn], [t].[Publisher], [t].[PurchaseLink], [t].[Id0], [t].[Description], [t].[Name0]
FROM [Authors] AS [a]
LEFT JOIN (
    SELECT [b].[Id], [b].[AudibleLink], [b].[AuthorId], [b].[Blurb], [b].[CategoryId], [b].[CoverImage], [b].[Isbn], [b].[Name], [b].[PreviewLink], [b].[Price], [b].[PublishedOn], [b].[Publisher], [b].[PurchaseLink], [c].[Id] AS [Id0], [c].[Description], [c].[Name] AS [Name0]
    FROM [Books] AS [b]
    INNER JOIN [Categories] AS [c] ON [b].[CategoryId] = [c].[Id]
) AS [t] ON [a].[Id] = [t].[AuthorId]
ORDER BY [a].[Id], [t].[Id]

The issue should have become apparent to us by the fact that we have to use Include for the related data, and the fact that we were able to breakpoint and debug into MapFromEntity methods which should have suggested to us that all the data was being returned from the database before performing the mapping locally in memory.

If we change the EF query to:

List<AuthorDto> authors = await _dbContext.Authors
    .Select(author => new AuthorDto
    {
        Id = author.Id,
        Name = author.Name,
        Books = author.Books.Select(book => new BookDto
        {
            Id = book.Id,
            Name = book.Name,
            CategoryId = book.CategoryId,
            CategoryName = book.Category.Name,
        }).ToList()
    })
    .ToListAsync();

Then the resulting SQL query is:

SELECT [a].[Id], [a].[Name], [t].[Id], [t].[Name], [t].[CategoryId], [t].[CategoryName], [t].[Id0]
FROM [Authors] AS [a]
LEFT JOIN (
    SELECT [b].[Id], [b].[Name], [b].[CategoryId], [c].[Name] AS [CategoryName], [c].[Id] AS [Id0], [b].[AuthorId]
    FROM [Books] AS [b]
    INNER JOIN [Categories] AS [c] ON [b].[CategoryId] = [c].[Id]
) AS [t] ON [a].[Id] = [t].[AuthorId]
ORDER BY [a].[Id], [t].[Id]

Now, with this approach, we’re only querying the data that we actually need and making proper use of projection. Excellent.

The problem is that I find the MapFromEntity method to be very useful for a clean separation of concerns.

We could have used AutoMapper, and we have on previous projects, but we moved away from that for various reasons like lack of static code analysis. Since getting rid of AutoMapper, we’ve never looked back, but that’s a different story.

Retaining MapFromEntity with Expressions

To allow us to still use our MapFromEntity pattern, we can use Expressions instead:

public record BookDto
{
    public int Id { get; init; }

    public string Name { get; init; } = null!;

    public int CategoryId { get; init; }

    public string CategoryName { get; init; } = null!;

    public static readonly Expression<Func<BookEntity, BookDto>> MapFromEntity = entity => new BookDto
    {
        Id = entity.Id,
        Name = entity.Name,
        CategoryId = entity.CategoryId,
        CategoryName = entity.Category.Name,
    };
}

public record AuthorDto
{
    public int Id { get; init; }

    public string Name { get; init; } = null!;

    public List<BookDto> Books { get; init; } = new();

    public static readonly Expression<Func<AuthorEntity, AuthorDto>> MapFromEntity = entity => new AuthorDto
    {
        Id = entity.Id,
        Name = entity.Name,
        Books = entity.Books.AsQueryable().Select(BookDto.MapFromEntity).ToList()
    };
}

Now, we can use our MapFromEntity pattern efficiently:

List<AuthorDto> authors = await _dbContext.Authors
    .Select(AuthorDto.MapFromEntity)
    .ToListAsync();

And we achieve the same optimised SQL as with direct projection (i.e. newing up the DTO in the EF query):

SELECT [a].[Id], [a].[Name], [t].[Id], [t].[Name], [t].[CategoryId], [t].[CategoryName], [t].[Id0]
FROM [Authors] AS [a]
LEFT JOIN (
    SELECT [b].[Id], [b].[Name], [b].[CategoryId], [c].[Name] AS [CategoryName], [c].[Id] AS [Id0], [b].[AuthorId]
    FROM [Books] AS [b]
    INNER JOIN [Categories] AS [c] ON [b].[CategoryId] = [c].[Id]
) AS [t] ON [a].[Id] = [t].[AuthorId]
ORDER BY [a].[Id], [t].[Id]

Conclusion

By embracing Expressions, we can retain our clean MapFromEntity pattern and still enjoy the benefits of EF Core’s projection capabilities. This approach keeps our codebase efficient and maintainable.

How to Eliminate Nested XML Issues in ASP.NET Core 6.0 SOAP Services

2023-11-03T09:03:20+00:00

Introduction

While creating a SOAP API in ASP.NET Core 6.0 with SoapCore, I ran into a problem: my XML response had an extra layer that shouldn’t be there. The system using the API couldn’t work with this additional nesting.

Looking for solutions in various StackOverflow discussions and even a past GitHub issue, nothing seemed to work.

So, the decision was made to try something else - CoreWCF.

To illustrate the impact of our changes, let’s compare the SOAP messages before and after the transition.

Before (SoapCore)

With SoapCore, our configuration was:

// Program.cs

using SoapCore;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services.AddSoapCore();
builder.Services.AddScoped<MyService>();

WebApplication app = builder.Build();

app.UseRouting();

app.UseEndpoints(endpoints =>
{
    endpoints.UseSoapEndpoint<MyService>(
        "/Service.asmx", 
        new SoapEncoderOptions(),
        SoapSerializer.DataContractSerializer);
});

app.Run();

// MyService.cs

using System.ServiceModel;

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    MyResponse MyRequest(MyRequest myRequest);
}

public class MyService : IMyService
{
    public MyResponse MyRequest(MyRequest myRequest)
    {
        return new()
        {
            OutputMessage = "Hello world"
        };
    }
}

// MyRequest.cs

using System.Runtime.Serialization;

[DataContract]
public class MyRequest
{
    [DataMember]
    public string InputMessage { get; set; }
}

// MyResponse.cs

using System.Runtime.Serialization;

[DataContract]
public class MyResponse
{
    [DataMember]
    public string OutputMessage { get; set; }
}

And our SOAP response had an extra element, MyRequestResult, which was causing issues.

// SOAP response

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <s:Body>
    <MyRequestResponse xmlns="http://tempuri.org/">
      <MyRequestResult xmlns:d4p1="http://schemas.datacontract.org/2004/07/ExampleApi" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <d4p1:OutputMessage>Hello world</d4p1:Message>
      </MyRequestResult>
    </MyRequestResponse>
  </s:Body>
</s:Envelope>

After (CoreWCF)

We made a few changes:

// Program.cs

using CoreWCF;
using CoreWCF.Channels;
using CoreWCF.Configuration;
using CoreWCF.Description;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<MyService>();
builder.Services.AddServiceModelServices();
builder.Services.AddServiceModelMetadata();

WebApplication app = builder.Build();

app.UseServiceModel(configure =>
{
    configure.AddService<MyService>()
        .AddServiceEndpoint<MyService, IMyService>(
            new BasicHttpBinding(BasicHttpSecurityMode.Transport), 
            "/Service.asmx");

    ServiceMetadataBehavior serviceMetadataBehavior = app.Services.GetRequiredService<ServiceMetadataBehavior>();
    serviceMetadataBehavior.HttpsGetEnabled = true;
});

app.Run();

// MyService.cs

using CoreWCF;

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    MyResponse MyRequest(MyRequest myRequest);
}

public class MyService : IMyService
{
    public MyResponse MyRequest(MyRequest myRequest)
    {
        return new()
        {
            OutputMessage = "Hello world"
        };
    }
}

We changed our data contracts to message contracts:

// MyRequest.cs

using CoreWCF;

[MessageContract]
public class MyRequest
{
    [MessageBodyMember]
    public string InputMessage { get; set; }
}

// MyResponse.cs

using CoreWCF;

[MessageContract]
public class MyResponse
{
    [MessageBodyMember]
    public string OutputMessage { get; set; }
}

And now the XML output is as it should be, without the extra layer.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Body>
      <MyResponse xmlns="http://tempuri.org/">
         <OutputMessage>Hello world</OutputMessage>
      </MyResponse>
   </s:Body>
</s:Envelope>

Conclusion

Switching to CoreWCF fixed our nested XML problem in our SOAP service in ASP.NET Core 6.0. If you’re facing similar issues, giving CoreWCF a try might do the trick.

Simplifying Null Handling in C# with Try Methods and Nullable Reference Types

2023-10-26T17:05:00+00:00

Introduction

As developers, we’re always looking for ways to write cleaner, more efficient code. One common scenario we encounter is the need to handle potentially null values safely. In C#, nullable reference types have been a significant step forward in my opinion, but they can sometimes lead to extra checks and assertions.

I recently stumbled upon a neat trick that simplifies this process and wanted to share it with my team - and now with you.

Problem

Let’s talk about our Try methods. These methods are a staple for error handling in C#. They return a bool indicating success or failure and an out parameter to return a value. When dealing with nullable reference types, however, they can introduce some friction with the compiler’s nullability checks.

Considering the following method signature:

public bool TryBlahem(out string? blahem) { ... }

When you use it like this:

if (!TryBlahem(out string? blahem))
{
  // We typically expect the blahem variable to be null here
  return;
}

// We typically expect blahem to never be null here, but we have to use the null forgiving operator to keep the compiler happy

You’d expect blahem to be null if TryBlahem returns false, and non-null if it returns true. However, the compiler requires us to use the null-forgiving operator to satisfy its nullability checks, which can be a bit of an eyesore and somewhat defeat the purpose of null checks.

Solution

Here’s where the MaybeNullWhen attribute comes into play. By decorating the out parameter with this attribute, we provide the compiler with the necessary information to understand the relationship between the return value and null state of the parameter.

Here’s how you can use it:

public bool TryBlahem([MaybeNullWhen(false)] out string? blahem) { ... }

With this in place, the compiler now understands that blahem could be null when TryBlahem returns false, and not null when it returns true. This allows us to avoid using the null-forgiving operator:

if (!TryBlahem(out string? blahem))
{
    // We still typically expect the blahem variable to be null here
    return;
}

// Compiler knows blahem will not be null here so no need to use null forgiving operator

This small change makes the code cleaner and the developer’s intent clearer. No more unnecessary null-forgiving operators!

But that’s not all. The C# language has a variety of attributes that can help with nullable analysis. These attributes provide hints to the compiler about how we expect our code to behave in terms of nullability. You can find a comprehensive list and their descriptions at the official Microsoft documentation: Nullable static analysis attributes.

Conclusion

Incorporating these attributes into your code can reduce the number of warnings and improve the clarity of your nullability contracts. It’s a small investment into your code quality that can pay off in readability and maintainability.

So next time you find yourself reaching for the null-forgiving operator, consider whether onme of these attributes could make your intention clearer and your code cleaner.

Effortless Debugging: Create a VS Code Extension to Copy Console Logs with a Click

2023-02-08T12:46:00+00:00

Introduction

When working with JavaScript/TypeScript projects, whether that’s React, Node, or something else, I often find myself needing to print out the value of a variable to the console.

To do this, I’d usually begin by typing out console.log and then copy and paste the variable name into the parameters to get console.log("foo", foo)

Easy enough, but can get quite repetitive and tedious. So, I thought, “it’d be cool if I could just click on a variable and automatically copy a console.log for it!” And then I thought, “I’ve been interested in how VS Code extensions work, so I sense a good opportunity here!”

Development

Implementing the command

Turns out, it was a lot easier than I expected. I started by reading the VS Code documentation on how to create your first extension.

With this setup, it was time to write my own code for my extension. This involved registering a new command with the vscode.commands.registerCommand method that VS Code provides. I placed this inside the activate method that was already present in the extension.ts file provided by the VS Code documentation mentioned in the last paragraph.

export function activate(context: vscode.ExtensionContext) {
	const disposable = vscode.commands.registerCommand("extension.copyVariableConsoleLog", function () {
		...
	});

	context.subscriptions.push(disposable);
}

I referred to the documentation to figure out how to get the currently selected text in the editor.

const editor = vscode.window.activeTextEditor;
const selection = editor?.selection;
const text = editor?.document.getText(selection);
const variableName = text?.trim();

Then, I learned how to copy this text to the clipboard, which can be done with:

vscode.env.clipboard.writeText("the text");

The final implementation of the extension.ts file:

import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
	const disposable = vscode.commands.registerCommand("extension.copyVariableConsoleLog", function () {
		const editor = vscode.window.activeTextEditor;
		const selection = editor?.selection;
		const text = editor?.document.getText(selection);
		const variableName = text?.trim();
		const consoleLog = `console.log("${variableName}", ${variableName});`;
		vscode.env.clipboard.writeText(consoleLog);
		vscode.window.showInformationMessage(`Copied ${consoleLog} to clipboard.`);
	});

	context.subscriptions.push(disposable);
}

Next, I added the command to the package.json file as such:

    "commands": [
      {
        "command": "extension.copyVariableConsoleLog",
        "title": "Copy Variable Console Log"
      }
    ],

That’s well and good, now I can highlight a variable, open up the command prompt inside VS Code, type in “copyVariableConsoleLog”, execute and then the console.log is saved to my clipboard!

This works, but there’s still a lot of typing to do. I wanted to see if I can add this command to the context menu that appears when you right-click anywhere in the editor.

To add the command to the context menu, you need to modify the package.json again, similar to how it was done when adding the command.

    "menus": {
      "editor/context": [{
          "command": "extension.copyVariableConsoleLog",
          "when": "editorTextFocus"
      }]
    },

It just works!

Adding a keybind

It would be even less effort if I had a keybind for this. Luckily, adding a keybind is just as easy as adding the command or context menu option. Another edit of the package.json file:

    "keybindings": [{
      "command": "extension.copyVariableConsoleLog",
      "key": "alt+ctrl+c",
      "mac": "alt+cmd+c",
      "when": "editorTextFocus"
    }]

And again… it just works!

Publishing

Now that the extension was complete, I wanted to share it with the world, and gain some understanding of how the publishing process works for VS Code extensions. Turns out, it was also very simple to do.

I followed the publishing extensions documentation, which details how to use the vsce command to package and publish your extensions.

I ran into an issue when trying to publish the extension via the command line vsce command. I created my PAT token as per the instructions, however I was getting permissions issues. After some extensive Google fu, I could not find a solution to the problem. Luckily, there was a way to manually upload the package file via a web page.

The result

Now I can speed up my development time by a few seconds by double-clicking a variable name, then pressing ALT+CTRL+C, and pasting the log wherever I need it ;)

Final words

This is the part where somebody tells me such a thing already exists, or that there was an easier way to achieve this. However, in the end, I’m at least happy to share that I’ve learned something new in the process.

How I Solved My React-Admin Form State Reset Issue

2022-03-11T13:00:00+00:00

The Problem

Recently, while working on a project using React-Admin, I encountered a frustrating issue. I had an Edit component with a TabbedForm set to pessimistic mode, and a custom data provider based on React-Admin’s simple REST provider. Everything worked fine until the server-side validation kicked in.

The validation rule was straightforward: it ensured that no two entities shared the same name. If the rule was violated, the server would correctly return a 400 error with a message, which I displayed in a toast notification. However, this is where the problem arose. Every time the server returned a 400 error, the entire form state would reset, wiping out all the progress the user had made. This was not only annoying but also a poor user experience.

The Investigation

I noticed that after the 400 error response, there was an additional HTTP request sent to the API to fetch the entity by ID again. This was the getOne method on the data provider being called, which resulted in the form being reset to its initial state.

The question was: how could I prevent the form state from being reset after a 400 response from the server?

The Solution

After some digging and experimenting, I found a solution that worked perfectly. The key was to override the onFailure behaviour of the form submission. Here’s the custom onFailure function I implemented:

const onFailure = (error: any) => {
    notify(
      typeof error === "string"
        ? error
        : error.message || "ra.notification.http_error",
      { type: "warning" }
    );
    // Avoiding the default refresh behavior via refresh()
  };

By doing this, I effectively stopped the form from refreshing and losing its state upon encountering a 400 error.

Why This Works

The onFailure callback is part of React-Admin’s CreateEdit component. By default, it performs certain actions when a submission fails, including refreshing the page. By customising this behaviour, I could keep the existing form state intact, even when the server responded with an error.

Reference

For those interested in the technical details or who might be facing a similar issue, you can find more information in the React-Admin documentation here: React-Admin CreateEdit documentation.

Conclusion

In the end, the solution was a simple tweak to the onFailure callback. I hope sharing my experience can help someone else facing a similar challenge.

mickmelon.dev

Optimising Entity Framework with Projection-Friendly Mapping

Introduction

The Initial Setup

Retaining MapFromEntity with Expressions

Conclusion

How to Eliminate Nested XML Issues in ASP.NET Core 6.0 SOAP Services

Introduction

Before (SoapCore)

After (CoreWCF)

Conclusion

Simplifying Null Handling in C# with Try Methods and Nullable Reference Types

Introduction

Problem

Solution

Conclusion

Effortless Debugging: Create a VS Code Extension to Copy Console Logs with a Click

Introduction

Development

Implementing the command

Adding the command to the context menu

Adding a keybind

Publishing

The result

Final words

Links

How I Solved My React-Admin Form State Reset Issue

The Problem

The Investigation

The Solution

Why This Works

Reference

Conclusion