Evaluating FNH versus EF core

[mwpowellhtx]

Hello, not a stranger to NH or FNH from back in the day, always filed it in the back of my mind whether I might need an ORM to consider once again. I have reached one of those crossroads.

I have a project in which I have been using EF and it has been working, for the most part, to a point. It is starting to show signs of stress EF is not designed to handle; one such is order of persistence matters, table A must be upserted in order for table B FK to be properly handled. From what I was reading, I do not think EF handles this case, and the one issue I was finding, closed as not planned. Not sure if perhaps NH is better at negotiating those kinds of cases.

Will try not to ramble on this part of the thread, and will try to keep aspects focused in and of themselves, if that helps. Cheers and best thanks so much 🍻 !

[mwpowellhtx]

Step backwards, and in general, our approach is "code first" and "database first" with the ORM standing in between, we do all the mappings therein to connect the dots. We do the code first, we model the database and manage rolling out the mods ourselves, for now. Neither here nor there really from a technical evaluation perspective except to outline our basic development strategy; from NH capability we would not need to lean on migrations and so forth, in that sense, for now.

[mwpowellhtx]

Database wise using pg currently on PostgreSQL 16. Language and runtime we are using of course dotnet, CSharp, net8 when we want a runtime target, and whenever possible netstandard in its most primitive lowest version possible, but for most things, that is 2.0, sometimes 2.1.

[mwpowellhtx]

ID wise we mainly use pg UUID (dotnet Guid). In one or two places as nullable when FK relationships may be optional.

[mwpowellhtx]

We use JSON columns in a couple of places, at least one of which I am in the process of breaking out into first class models and database structure, which is part and partial my motivation for posting this discussion, having apparently run into an EF inability to properly order persistance reduction.

[fredericDelaporte]

There is currently no handling of JSON types in NHibernate. But you may create your own custom type for that purpose. Or just map them as string if that can work for postgresql.

[mwpowellhtx]

There are some cases where we have decimal modeled as NUMERIC() for the most part. And a couple other cases in which we model a LONG, ULONG, and such as this, persisting key elements for discord and so forth. So ability for FNH or NH to negotiate that would be helpful, or with minimal training.

[fredericDelaporte]

Should be supported out of the box.

[mwpowellhtx]

We are also modeling time based components for the most part using NodaTime, so proper support for things like Duration, Interval, Instant are also important. Duration elements generally I end up converting those to total seconds for persistence purposes. In one or two instances when we need a proper NodaTime support then rather we're talking about that; INTERVAL database mapping. Wonder if NH can handle that, or at least we can train NH how to handle it.

[fredericDelaporte]

Using custom types is the way to go too. A quick search shows that it seems there is a bunch of projects for that, like https://github.com/jmojiwat/NHibernate.UserTypes.NodaTime or https://github.com/MatthewRudolph/Airy-Nhibernate-Extensions

[mwpowellhtx]

Sure thanks. I've seen a number of repos in the wild, but I may look at that for internal ideas, feature parity, etc.

[mwpowellhtx]

Added notes below, but to reiterate, I'm not sure what int64 is to NodaTime.Duration. Our database mapping based on efcore interpretations to pg dialects is to use INTERVAL, not anything like int64, to my knowledge.

[fredericDelaporte]

Int64 is the default DbType NHibernate uses for mapping TimeSpan. That is the most cross-vendor type, most databases handle that type. That does not prevent an user type to choose another DbType.

[mwpowellhtx]

Of course we have lots and lots of parent child relationships. The primary case (above 1P) we bumped into we are factoring from a previously JSON column property, to a proper 1-many relationship. If we can do that with a joining table, even better, although I understand opinions may vary in this area; there are reasons why a joining table might be considered beneficial, i.e. properties on the relationship that do not really need to be on either of the two participating types.

For the most part we use ICollection<T> there for those as well, and behind that we also make sure those are ObservableCollection<T> and connect the CollectionChanged EH in order to handle appropriate bidirectional reference handling.

I am somewhat familiar with the NH approach therein having worked with it in the past. I'm sure the story has only gotten better to present.

[mwpowellhtx]

We also lean heavily on CommunityToolkit.Mvvm for ObservableObject<T> and make judicious use of the INPC pattern. Again, understandable there are different opinions about the efficacy of doing this, models, versus view models, versus views, the venerated DTO anti-pattern (my personal opinion), and so on. Don't get me wrong, there are reasons for a DTO, but in our case, at present, we do not have those reasons.

It is worth mentioning, our primary targets are into a dotnet core WPF environment. For the most part, we prefer direct engagement with the out of session model instances, as they lean on INPC heavily to communicate with MVVM bindings. Frequently we also wrap instance targets for more elaborate view model bindings.

So far, except for one or two INPC over steps, that has been a fairly good approach for use to be using.

[mwpowellhtx]

From an NH perspective, I expect to load models in and run with them essentially disconnected from the NH session. When we are ready to persist, then we make a new DI request for session (via repository abstraction).

[mwpowellhtx]

One aspect I was finding, when there are existing parent child relationships, EF was pretty good at negotiating the positive image, when those existed. But was horrible at navigating the negative image; that is doing the necessary deletion when collection content has changed.

It's been a little while, but I wonder if NH, and ORM in general, are really built for that case. I was finding I had to do some manual reconciliation, set differences, etc, and run the deletion myself in the business logic interfacing the repository pattern. That's one aspect.

[mwpowellhtx]

Then of course I was starting to model a proper one-to-many, but EF was counting that as a cycle. That coupled with eagerly loaded references, children, etc, which we want, not for lazy loading, at least for now, unless that can be done transparently that is.

We have a lot of pattern matching going on, and wrapping into specially targeted views, so that may be prohibitive of the lazy loading code generation features, I'm not sure; at least it was with EF, so LL was a non starter.

In terms of OTM, ideally our preference is for a joining table, in which there are also additional properties specially attributed to that joining relationship. HOWEVER, with EF, we tried mapping that rather to the source table, including those attributes; and then ran into EF cycles.

[fredericDelaporte]

NHibernate lazy loading supports batching of lazy loads, which can achieve performances on par with eager loading, depending on the cases. But of course, the session must be still opened and the entities bound to it for lazy-loading to work, which may not suit your needs.

NHibernate eager loading capabilities are far from EF ones. Eager loading of many collections with NHibernate will lead to Cartesian products with results duplication and poor performances, which did not happen with EF (6 at least, I have not tried the core one; and EF does that by generating convoluted queries which may bring their own troubles).

[mwpowellhtx]

Those are the highlights and a bit of insight into what we're about re: ORM, EF (possibly NH+FNH) and so forth. Would love to learn is it a good choice our reconsidering the ORM, into NH+FNH, and so on. We're at a point in the mapping, dozen or so classes, and for NH type hierarchy perhaps as well, so do not want to just automatically embark on this path and realize it was a horrible decision.

[fredericDelaporte]

Though I am still marginally active as a NHibernate contributor, I am no more using a full fledged ORM at work since long. I use micro-ORM like Dapper. So, I am not in a position to advise on this.

[mwpowellhtx]

Thanks for the feedback @fredericDelaporte and in advance others. So at the moment looks like very well feasible and so forth. Just a matter of scope, timing, priorities, etc. Appreciate the responses, and caveats of course.

[mwpowellhtx]

One follow on question FNH dependencies... I do not see any NH package deps? How is that even possible? NH is baked into the cake?

[fredericDelaporte]

What do you mean?

https://www.nuget.org/packages/FluentNHibernater

[mwpowellhtx]

Does it depend upon NHibernate seems like it does not. So rather it is a full fledged adaptation of NH, yes?

[fredericDelaporte]

No, it depends of NHibernate, as shown above.

[mwpowellhtx]

Starting the transition to FNH... EF has an optimization concept of "split queries", I see FNH and NH have something similar in the Fetch strategy, which is fantastic, is that accurate? So instead of IQueryable<T>.AsSplitQuery() I need to configure .Fetch.Something() or what not, correct? Otherwise there are just a metric ton of mangled compounded joins which eventually blow up the database engine.

[fredericDelaporte]

It will be way worse, see this previous comment.

I do not remember if something similar to EF Core split queries can be done with NHibernate eager loading.

I was always using batched lazy loading instead. (Calling NHibernateUtils.Initialize on lazy associations if needing to trigger their loads, especially useful if willing to use its async version in order to load them asynchronously.)

[mwpowellhtx]

Well hopefully not, but thank you for the heads up at any rate. Will cross the bridges that are there to cross as I find them.

[mwpowellhtx]

Any advice on a halfway decent IUserType implementation? Approaching that issue, I'd like to define them in a somewhat generic <T, U> way up front, then specialize only the parts that need specializing. Most of the time that is the Serialize or Deserialize supporting methods.

As well as to and from types of course.

And also the NullSafeGet and set. Default implementations might be something like this (draft):

public abstract class UserColumnCustomType<T, U> : IUserType
    where U : IEquatable<U>
{
    public virtual new bool Equals(object x, object y)
    {
        if (x is not T left || y is not T right)
        {
            return false;
        }

        return left is null && right is null || ConvertTo(left).Equals(ConvertTo(right));
    }

    // ...
    public virtual object NullSafeGet(DbDataReader rs, string[] names, ISessionImplementor session, object owner) =>
        NHibernateUtil.Custom(typeof(U)).NullSafeGet(rs, names, session, owner) is U returnValue ? returnValue : (object)default(U);
}

Set side of things is in progress, working out what I will need for Serialize, Deserialize at the moment.

In practical use, most of the time I do this for pg JSON columns, so one side is fairly statically defined, but there may be odd instances in which the target database type(s) are something other than JSON (or String(N)), for instance.

Equals(object, object) is also potentially snafu problematic, as long as I have the conversions to from sorted, then perhaps that is an adequate baseline implementation. But allowing for that to be specialized as well as needed.

Thanks in advance for any insights. Cheers 🍻 !

[mwpowellhtx]

Also from a usage perspective, I'm not sure I like the fluent mapping for custom types either, not sure there is a better method, extension method, way of doing that just at the moment, have not dug into it much yet. i.e.

Map(x => x.MyProperty)
    .CustomType<MyColumnCustomType>()
    ;

This seems to be the only manner in which I may instruct FNH as to custom columns. There does not seem to be much opportunity to configure, inject, whatever, which maybe is for the best, but still, might like some flexibility there. Again without having dug into second and third levels of separation. i.e.

Map(x => x.MyProperty)
    .CustomType<MyColumnCustomType>(ct => ct.ConfigureSomething())
    ;

I might like to inject things like JSON serialization instructions, depending on the use case, etc, that sort of thing. Or God knows what else, but at any rate, that's the supposed question there.

Cheers 🍻 !

[mwpowellhtx]

And this minor tweak allowing for extensibility during Equality challenges.

/// <summary>
/// Override in order to perform custom Equality comparisons of the target
/// <typeparamref name="U"/> mapping.
/// </summary>
/// <param name="left"></param>
/// <param name="right"></param>
/// <returns></returns>
protected virtual bool Equals(T left, T right) => ConvertTo(left).Equals(ConvertTo(right));

public virtual new bool Equals(object x, object y)
{
    if (x is not T left || y is not T right)
    {
        return false;
    }

    return (left is null && right is null) || Equals(left, right);
}

[mwpowellhtx]

Ruh roh, so... some stipulatons impeding progress.

So far, what I can glean, a simple if naive custom type mapping to JSON assumes string baseline. All well and good. But perhaps we can do better, and properly talk with the pg database dialog JSON type. That's the first observation.

Second, what to do about NodaTime dialects. NodaTime is pretty well supported by pg by design. There are also efcore dialects making it possible. We use for instance Duration in a number of places. However, there seems to be a dearth of such dialect extensions for NH, and the ones that do seem to exist for NodaTime, do not support pg, let along mappings to database INTERVAL type, for example.

For this to be a viable path forward, not sure that we would need HQL level support. So if that simplifies the scope, excellent news.

Open to ideas approaching that baffle.

[mwpowellhtx]

There are zero comments on either of these. What are they about? DefaultValue somewhat self-explanatory, I'm assuming in the desired modeled type, i.e. NodaTime.Duration.Zero.

class PrimitiveType
{
    abstract System.Type PrimitiveClass { get; }

    abstract object DefaultValue { get; }
}

But what of PrimitiveClass (?). Is that of System.TimeSpan (?) or even string (?). Given we also specify ReturnedClass, i.e.

override System.Type ReturnedClass { get; } = typeof(NodaTime.Duration);

[mwpowellhtx]

Then there is the matter of "registering" or at least in terms of FNH... I am not seeing any means of registering, or is the existence of PrimitiveType declaration sufficient? A la Fluent parlance.

[fredericDelaporte]

Deriving directly from a NHibernate type instead of implementing an user type requires quite more work. And as you can see, it is not much documented. There is no support for it, you on your own. PrimitiveClass is the .net type that should be yielded by the NHIbernate type when reading values. Registration is done from the TypeFactory and from mapping of DbType in the dialects. That is digging in many internals of NHibernate.

This has to be done if you want to contribute the type into NHibernate. But as you want to yield Noda types, that would mean adding Noda as a NHibernate dependency, which we are unlikely to do.

If you just want to implement thme for you own use, implementing user types should a lot more easier.

[mwpowellhtx]

I get it, yes; and thank you for the guidance re: project assembly strategies, dependencies, and so forth.

[fredericDelaporte]

About the Get overload with a name, it is obsolete, and no more called at any time by NHiberante. You can just throw an exception if you wish, if you derive from a type that does not have a base implementation and you are forced into providing an implementation.
We are not removing it yet for complying with SemVer. It could be removed only in a new major version.

[mwpowellhtx]

Going to go ahead and close. Appreciate the summaries and responses.