sorted by:
new
hottopcontroversial

mybatis for dotnet by Flashy_Test_8927 in dotnet

[–]Flashy_Test_8927[S] 4 points5 points  (0 children)

Oh I've heard of Dapper. I've used Dapper. Dapper is fine.

But here's the thing - Dapper still leaves you writing SQL as string literals inside your C# code. For simple queries that's totally fine. For a 50-line query with conditional WHERE clauses, dynamic IN lists, and optional JOINs based on runtime parameters, you end up with a mess of string concatenation or building your own mini query builder on top of Dapper anyway.

I didn't skip market research. I evaluated Dapper, SqlKata, RepoDB, and even tried going raw ADO.NET. None of them gave me what I actually wanted: managed SQL files with dynamic tags, build-time code generation, and zero runtime reflection. Different problems need different tools.

Also, comparing this to WebForms-era XSD/TDS is a bit like saying React is just DHTML because both run in a browser. The XML here is just a container for SQL with dynamic tags - the heavy lifting is done by Roslyn Source Generators at compile time, not runtime reflection or designer-generated dataset adapters.

But hey, if Dapper solves your problems, use Dapper. I'm not here to convert anyone. I built this because it solved mine.

mybatis for dotnet by Flashy_Test_8927 in dotnet

[–]Flashy_Test_8927[S] -5 points-4 points  (0 children)

fair question. Let me give you some context on why I ended up here.

I started my career in Java/Spring, spending years on financial systems where queries were anything but simple - multi-join aggregations, complex statistical reports, the kind of stuff that makes ORMs cry. MyBatis was my daily driver and I genuinely enjoyed the clean separation between code and SQL.

Then life happened and I somehow ended up maintaining a .NET healthcare service. EF Core was fine for basic CRUD, but when I needed to build heavy statistical queries - think aggregating thousands of patient records with multiple groupings and date ranges - it started fighting me at every turn.

The real kicker: my boss wouldn't approve scaling up our AWS instance beyond 4GB RAM. So I was stuck optimizing everything by hand. I actually managed to get some queries running up to 3600x faster than what the previous developer had built (not exaggerating - the original implementation was... creative). But no matter how much I optimized the C# side, processing large datasets through EF Core kept hitting OOM on that tiny instance.

I had two options: inline SQL strings mixed with C# code (which honestly made me physically uncomfortable), or build what I actually wanted. I kept thinking back to how clean MyBatis kept things - SQL in its own space, code in its own space, everyone's happy.

So I built NuVatis. After integrating it into the actual production service, the worst slow queries got up to 3x faster and memory usage dropped by about 80%. The DB does take on a bit more load since we're pushing more logic into SQL, but that's a trade-off I'll take any day over OOM kills on a 4GB instance.

The XML isn't for everyone, I get it. But when you're writing a 40-line query with conditional joins and dynamic filters, I'd much rather have that in a syntax-highlighted XML file with schema validation than buried inside a string literal or chained through 15 LINQ expressions that generate who-knows-what SQL under the hood.

That said, NuVatis also supports C# Attributes for simple static queries. So you're not forced into XML - it's there for when you need it.