Why Dapper.QX?

I know that inline SQL is a divisive topic. I love and use Linq to objects often, but have never enjoyed Linq to Entities because I don't like how it handles dynamic criteria, its strange outer join syntax, and the complications around debugging and working with generated SQL.

At the same time, it's true that thoughtless use of inline SQL makes application code brittle and complicated. With this in mind, I created Dapper.QX as both a productivity layer and a testing framework for inline SQL. I based it on Dapper since it handles low-level query execution and mapping of results to CLR types really well.

Productivity in query applications means having a good way to handle dynamic predicates as well as ending up with readable code. Dapper.QX lets you mix and match criteria in a type-safe and concise syntax using ordinary C# object literals. Dapper.QX does not use lambdas nor generate any SQL apart from using AND to join the terms of your WHERE clauses. In this way, you can:

• Use any SQL feature supported by your platform. Dapper.QX is platform-neutral because Dapper is.
• Not be surprised by mysterious generated SQL nor be limited to expressions that support Linq translation
• Write code that conveys intent in a way that a screenful of SQL does not. Query classes have a single responsibility, and can be executed in a concise way.

See the In a Nutshell topic to see Dapper.QX in use.