Skip to main content

NHibernate–Using record types

At one of my customers, we have been using NHibernate for a really long time. And although I think that with the latest Entity Framework Core, the feature set is almost on par, we are still using NHibernate today.

Of course, we want to use the newest C# features including Record types.

Let’s see if (and how) we can use record types in combination with NHibernate.

Here is a simple record type using positional parameters:

And the mapping code using Fluent NHibernate:

If we try to use this type in our application, NHibernate starts to complain with the following error message:

   ---- NHibernate.InvalidProxyTypeException : The following types may not be used as proxies:

    Tests.Domain.Category: type should have a visible (public or protected) no-argument constructor

    Tests.Domain.Category: method Deconstruct should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method get_Id should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method set_Id should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method get_CategoryName should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method set_CategoryName should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method get_Description should be 'public/protected virtual' or 'protected internal virtual'

    Tests.Domain.Category: method set_Description should be 'public/protected virtual' or 'protected internal virtual'

This makes sense as in NHibernate by default lazy loading is enabled. To use lazy loading a proxy class need to be created and this requires that all properties are declared virtual.

In this case I don’t need lazy loading for this class, so let’s disable this in our mapping file:

This solves a part of the errors above. If we try to run our application again, we still got an error:

FluentNHibernate.Cfg.FluentConfigurationException : An invalid or incomplete configuration was used while creating a SessionFactory. Check PotentialReasons collection, and InnerException for more detail.

    ---- NHibernate.InstantiationException : Object class NHibernate.Tests.Domain.Category must declare a default (no-argument) constructor

NHibernate needs a (private) default constructor without arguments to be able to create the type. As we are using a positional Record type, only a constructor with the 3 properties as argument is available. Although some ‘hacks’ exist to get rid of this error in NHibernate, the easiest solution is to switch to the standard property syntax and introduce an extra constructor:

Popular posts from this blog

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

.NET 8–Keyed/Named Services

A feature that a lot of IoC container libraries support but that was missing in the default DI container provided by Microsoft is the support for Keyed or Named Services. This feature allows you to register the same type multiple times using different names, allowing you to resolve a specific instance based on the circumstances. Although there is some controversy if supporting this feature is a good idea or not, it certainly can be handy. To support this feature a new interface IKeyedServiceProvider got introduced in .NET 8 providing 2 new methods on our ServiceProvider instance: object? GetKeyedService(Type serviceType, object? serviceKey); object GetRequiredKeyedService(Type serviceType, object? serviceKey); To use it, we need to register our service using one of the new extension methods: Resolving the service can be done either through the FromKeyedServices attribute: or by injecting the IKeyedServiceProvider interface and calling the GetRequiredKeyedServic...

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...