David Sexton edited this page Aug 28, 2016 · 2 revisions

Drapper is a control and neatness freaks ORM. It's intention is to keep .NET and SQL code separated from each other while still providing a clean, concise API that puts you in control.

Drapper allows you to build complex object graphs from your data with ease as well as persist objects in a consistent, predictable and reliable way.

Drapper was built on top of the Dapper Micro ORM and works across all the same providers supported by Dapper including SQLite, SQL CE, Firebird, Oracle, MySQL, PostgreSQL and SQL Server.

Quick Look

The heart of Drapper is the IDbCommander. It's an interface which exposes overloads of only 2 methods - Query and Execute. Query is used for data retrieval operations while Execute is used for persistence/data changing operations. Both methods come in Async flavours as well.

Query

IDbCommander _commander;

// retrieve all
_commander.Query<Country>()

// retrieve with parameters
_commander.Query<Country>(new { language = "English" });

// retrieve single
_commander.Query<Country>(new { code = "ZA" }).SingleOrDefault();

// map complex types
_commander.Query<Country, Currency, Country>(
    (country, currency) => 
    { 
        country.Currency = currency; 
        return country; 
    });

// map _really_ complex types
_commander.Query(Map.ReallyComplexMapping); // where Map.ComplexMapping is a Func<> with up to 16 inputs!

Execute

// all persistence operations are transactional. 
// transactions spanning multiple instances are automatically
// escalated to DTC. 

// persist a complex type
_commander.Execute(country);

// persist an object graph. each Execute call
// can target a different database instance if 
// you need it to! 
_commander.Execute(() => 
    {
        _commander.Execute(country);
        _commander.Execute(country.Currency);
        _commander.Execute(country.States);
    });

Why should I use Drapper?

Ever just wanted to execute a bit of SQL without jumping through the hoops imposed by other frameworks? Are you annoyed by the quirks of the monolithic ORM's? Tired of the limitations their design impose on your code? Tired of fighting the framework?

Then Drapper is for you. Drapper deliberately stays out of your way allowing you the choice of how to build your application your way.

You provide Drapper with the SQL to be executed. There is no auto-generated SQL. You will know the needs of your application better than any auto-generated SQL provider. That said, if you really do want auto-generated SQL you can plug this into Drapper by implementing an ICommandReader that will return a CommandSetting for you.

Other Good Stuff

  • Drapper keeps your SQL and .NET code separate from each other. So if your schema changes, or you need to switch from a SQL statement to a stored procedure, or if you need to switch to an entirely different instance or data provider -- or any of the hundreds of different changes we face in day to day development - you can do it with ease. No recompiliation needed.

  • Drapper supports storing your SQL statements in any fashion you choose. It supports json and xml config files right out of the box.

  • Drapper supports async/await for asynchronous code.

  • Speed! Being built on top of the Dapper MicroORM Drapper inherits the speed advantage that Dapper gives you over more traditional frameworks. Although a little bit of speed is sacrificed in using Drapper, it is still many times faster than the monoliths.

  • Pluggable - all the major parts of Drapper are derived from interfaces. If you don't like that component, replace it.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.