This is a general comment on the existing systems, not about one of them in particular.
Instead of starting with an existing system (since it sounds like both of them would require substantial work to match up with where our MVP seems to be going), can’t we build a new system but take advantage of existing components when they exist and fit? It doesn’t have to be all-or-nothing. Maybe one of the existing systems has 90% of the database schema we want. Maybe one of them is 80% there on basic front-end mechanics. Maybe neither of them does login well but one of them has some bits that mean we don’t have to start from scratch. Etc.
We should design and architect what we need without being bound by other systems’ design debt, but we should not fall into the “not invented here” trap and insist on writing everything ourselves if there’s something we can more-easily adapt.
I don’t know how to translate this into a vote, so I haven’t voted.
My grand reasoning for that is (drumroll…) “we use it at work”. NHibernate and Vue were 2 technologies I didn’t have exposure to yet. So I started a new hobby project, as one is wont to do. Making it a Q&A website was happenstance - it’s an easy to comprehend feature set, plus I didn’t want to think about layout etc so much. Why my company chose NHibernate, that decision was made roundabout a decade ago and the people that decided that are not here anymore.
That aside, let me still pass judgement from my time of using it:
It’s… solid. Simple to medium queries you pretty much just do in LINQ, but there’s also type-safe advanced stuff for projections etc. Another bonus is that it has a proven track record.
EF I used for the hobby project that I abandoned for this one That was a shorter period though. From what I can tell so far, it also seemed pretty solid. In the short time working with it I did not find a good solution to mocking the DB… but then in Answers I ended up using an in-memory-DB for those tests, and that part is actually easier in EF (it’s provided out of the box; not a huge difference though).
linq2db, I don’t know it. They say on their own website that they’re just one step above Dapper (concerning complexity).
I heard good things about the combination “Dapper for reads, NHibernate for writes”. That way you can optimize your reads in almost bare-metal, but still injection safe SQL - while you can do the writes in a more high level language approach. Used like this, I don’t see a huge difference between NHibernate and EF. And possibly linq2db, but I’m assuming it’s worse than NH/EF at alsmot-forget-that-theres-a-DB-writing, and it’s very probably worse at high-peformance reading than Dapper.
That was a shorter period though. From what I can tell so far, it also seemed pretty solid. In the short time working with it I did not find a good solution to mocking the DB… but then in Answers I ended up using an in-memory-DB for those tests, and that part is actually easier in EF (it’s provided out of the box; not a huge difference though).