RTS Questionnaire · Question 06 of 52 · file: answers/q06.html
Have you worked with EF Core, Dapper, or other ORM/data-access frameworks?
.NETData AccessORM
✅ Yes — I have used ORMs and micro-ORMs across both the .NET and JVM ecosystems, and I choose between them deliberately.
🧪 Interactive proof: this answer has its own page with a live data-access workflow, the code behind it and the acceptance criteria — open the Q06 data-access proof →
Technical detail
- 🟪 Entity Framework / EF Core — code-first modelling, migrations,
DbContextlifetime management in DI, LINQ queries translated to SQL, relationships and owned types, compiled queries, split queries,AsNoTrackingfor read paths, concurrency tokens and explicit transactions. - ⚡ Dapper — micro-ORM for performance-critical, read-heavy or stored-procedure-driven paths where I want exact SQL control with minimal mapping overhead, using parameterised queries and multi-mapping for joins.
- 🟧 Other data-access stacks I bring in — Hibernate/JPA and Spring Data on Java, SQLAlchemy on Python/Flask, ADO.NET and T-SQL/PL-SQL for hand-tuned hot spots, plus Repository + Unit of Work abstractions to keep the domain clean and testable.
🧠 Rule of thumb I apply: EF Core for the majority of the domain and transactional writes, Dapper for reporting-style queries and latency-sensitive screens, and raw SQL when the optimiser needs explicit hints. 🧪 Both are wrapped behind interfaces so persistence can be swapped or mocked in tests, and every query is reviewed with execution plans before release.
🧾 CV evidence: CV .NET Technologies line explicitly lists Entity Framework (EF) plus REST in .NET; Hibernate/JPA and relational database depth in the Java track; Repository pattern experience and SQL Server/SSIS data integration background.