dotnet-data-access (ORM hub)

Owns the .NET side of talking to a database, the part that is the same whichever full ORM you use. Load the per-ORM reference for the concrete mechanics:

• EF Core -> references/efcore.md
• NHibernate -> references/nhibernate.md
• .NET Framework 4.8 (EF Core 3.1 vs EF6, DbContext-per-request) -> references/net-framework-48.md

Out of scope, by design: raw SQL / index / planner tuning -> postgres or sqlite; the migration safety playbook (expand-contract, backfill, rollback, never edit an applied migration) -> dotnet-migrate; async / CancellationToken / hand-mapping -> csharp; real-DB integration tests -> dotnet-testing.

Session lifetime and thread-safety

• The unit-of-work object (EF DbContext, NH ISession) is not thread-safe and is short-lived - one per web request or per background unit of work. Never share it across requests or threads.
• The factory is the expensive singleton, built once at startup (EF via DI / AddDbContextFactory, NH ISessionFactory). Long-lived or parallel owners open a fresh session/context per operation from the factory - never hold a captive short-lived one on a singleton.
• Bulk / ETL work uses the tracking-free fast path (EF no-tracking, NH IStatelessSession).

Identity map and change tracking