Docs / Philosophy

Philosophy

What this page covers#

This page explains the design philosophy behind MooDb.

The short version#

MooDb is designed to be:

  • small
  • explicit
  • SQL Server first
  • stored procedure first
  • predictable
  • easy to adopt

Why MooDb exists#

A lot of database code sits in an awkward middle ground.

Raw ADO.NET is powerful, but it can be repetitive and easy to get wrong. Larger ORMs can remove a lot of boilerplate, but they also bring more surface area, more abstraction, and more behaviour to understand.

MooDb tries to sit in the middle.

It removes repetitive plumbing while still keeping the database work visible.

The main ideas#

Stored procedure first#

The main MooDb surface treats the command text as a stored procedure name.

That makes stored procedure usage the default path, not just one option among many.

Raw SQL is explicit#

Raw SQL is still supported, but it lives on db.Sql.

That keeps SQL text visible and deliberate instead of mixing it into the stored procedure-first path.

Small public surface#

The core product surface is intentionally small:

  • MooDbContext
  • MooTransaction
  • MooSql
  • MooParams
  • IMooMultiReader
  • MooBulk
  • MooDbContextOptions

Predictable mapping#

MooDb supports automatic mapping for common cases and custom mapping for the cases where you want more control.

MooDb also puts more emphasis on mapping behaviour being consistent and predictable, especially when strict auto mapping is enabled.

Less plumbing at the call site#

MooDb aims to keep connection, command, reader, and disposal plumbing out of the way in normal usage so the call site stays focused on the actual database operation.

SQL Server-specific on purpose#

MooDb is not trying to be all things to all databases.

It openly embraces SQL Server-specific concepts such as:

  • SQL Server parameter types
  • table-valued parameters
  • SQL Server transactions
  • SQL Server bulk copy

That makes the API more focused and easier to reason about when SQL Server is your target.

Why this matters to beginners through to advanced users#

A user does not just need an API reference.

They need to know what they are looking at and why the library is shaped the way it is.

The philosophy matters because it explains why MooDb looks different from both raw ADO.NET and a more general-purpose micro ORM.

Once that makes sense, the rest of the API usually feels much easier to understand.