Tutorial by Examples

Dapper makes it easy to follow best practice by way of fully parameterized SQL. Parameters are important, so dapper makes it easy to get it right. You just express your parameters in the normal way for your RDBMS (usually @foo, ?foo or :foo) and give dapper an object that has a member called foo...

Sometimes the convenience of a parameter (in terms of maintenance and expressiveness), may be outweighed by its cost in performance to treat it as a parameter. For example, when page size is fixed by a configuration setting. Or a status value is matched to an enum value. Consider: var orders = conn...

A common scenario in database queries is IN (...) where the list here is generated at runtime. Most RDBMS lack a good metaphor for this - and there is no universal cross-RDBMS solution for this. Instead, dapper provides some gentle automatic command expansion. All that is requires is a supplied para...

Sometimes, you want to do the same thing multiple times. Dapper supports this on the Execute method if the outermost parameter (which is usually a single anonymous type, or a domain model instance) is actually provided as an IEnumerable sequence. For example: Order[] orders = ... // update the tot...

Some ADO.NET providers (most notably: OleDB) do not support named parameters; parameters are instead specified only by position, with the ? place-holder. Dapper would not know what member to use for these, so dapper allows an alternative syntax, ?foo?; this would be the same as @foo or :foo in other...