implementing-ef-core

Repository Pattern

EF implementations live in src/Infrastructure/EntityFramework/Repositories/. Each class implements the same interface as its Dapper counterpart. The EF repository uses DbContext and LINQ queries instead of stored procedures, but must produce identical behavior.

Why behavior must match stored procedures exactly

Bitwarden self-hosted runs on the customer's choice of database. If CipherRepository.GetManyByUserId() returns results in a different order on PostgreSQL than the stored procedure returns on MSSQL, or filters differently, or handles nulls differently — that's a bug. Users switching databases or comparing behavior across environments will see inconsistencies.

The [DatabaseData] integration test attribute runs the same test against all configured databases. This is the primary safety net for parity.

Cross-database considerations

EF Core's LINQ-to-SQL translation varies by provider. Patterns that work on one database may fail on another:

• PostgreSQL is stricter about types — operations like Min() on booleans or implicit string/int conversions that MySQL allows will throw
• SQLite has limited ALTER TABLE support — some migrations that work elsewhere fail on SQLite
• Case sensitivity depends on database collation, not on C# code — don't assume case-insensitive string comparison

The pragmatic approach: write clean LINQ, run [DatabaseData] tests, and fix provider-specific failures as they surface rather than trying to predict every edge case.