Pitfalls of relational DB access in .NET: rethinking micro-ORMs
ADO.NET and Entity Framework (EF): one is 17-years-old and archaic; the other is painfully slow and barely functional for anything more complex than "select * from Foo". But you just use Dapper, or a similar micro-ORM. Have you chosen wisely?
This void between ADO.NET and EF has been ignored by Microsoft, which has led to proliferation of third-party libraries which all try to come up with the best mix of simple APIs and data-access-patterns delivering the power and speed of ADO.NET. One example of such micro-ORM library is Dapper. When neither ADO.NET nor EF are fit for the task at hand, how does one decide what micro-ORM to choose? "For every complex problem there is an answer that is clear, simple, and wrong."
We’ll rethink what makes a good micro-ORM library, and compare ADO.NET, EF, and most existing state-of-the-art micro-ORM libraries, considering not only performance benchmarks but also architecture, design, APIs, and advanced features.
You will come away with a deep understanding of tradeoffs and optimizations involved in building a good micro-ORM library, which will help you not only make the right micro-ORM decision for your tasks and teams, but perhaps even write your own micro-ORM, or contribute to existing OSS libraries.
This is an advanced-level talk which covers low-level ADO.NET, various micro-optimizations & tricks, connection, transaction, and query patterns, etc. as well as high-level architectural concepts and advanced micro-ORM features. While you’re dreaming about a Raspberry Pi IoT with a custom-GC running Apache Kafka, come to learn about what you actually do at work.