Permalink
Browse files

fixing README examples and backticks

  • Loading branch information...
1 parent 907f26f commit d4a43c9732857c4b9e374f6f74f22fe88c4e033c @half-ogre committed Jun 30, 2012
Showing with 10 additions and 7 deletions.
  1. +10 −7 README.markdown
View
17 README.markdown
@@ -1,24 +1,27 @@
-`DapperWrapper` is a library that wraps the [Dapper]() extension methods on `IDbConnection` to make unit testing easier.
+DapperWrapper is a library that wraps the [Dapper](http://code.google.com/p/dapper-dot-net/) extension methods on `IDbConnection` to make unit testing easier.
-Why bother? Because stubbing the extension methods used in a method-under-unit-test is a pain in the ass. For instance, you can't just use a library like [Moq]() to stub the `.Query` extension method on a fake `IDbConnection`. To work around this, I introduce a new abstraction, `IDbExecutor`.
+Why bother? Because stubbing the extension methods used in a method-under-unit-test is a pain in the ass. For instance, you can't just use a library like [Moq](http://code.google.com/p/moq/) to stub the `.Query` extension method on a fake `IDbConnection`. To work around this, I introduce a new abstraction, `IDbExecutor`.
## The `IDbExecutor` Interface
-The IDbExectuor interface has four methods, each corresponding to one of the four Dapper extension methods: `Execute`, `Query`, `Query<T>`, and `QueryMultiple`. Wherever you would previously inject an IDbConnection to use with Dapper, you instead inject an `IDbExecutor`. There is a single concrete implementation of `IDbExecutor` included in `DapperWrapper`, `SqlExecutor`, that uses the `Dapper` extension methods against `SqlConnection`. Adding your own `IDbExecutor` against other concrete implementations of `IDbConnection` is easy.
+The `IDbExectuor` interface has three methods, each corresponding to a Dapper extension method: `Execute`, `Query`, and `Query<T>`. Wherever you would previously inject an `IDbConnection` to use with Dapper, you instead inject an `IDbExecutor`. There is a single implementation of `IDbExecutor` included in DapperWrapper, `SqlExecutor`, that uses the Dapper extension methods against `SqlConnection`. Adding your own `IDbExecutor` against other implementations of `IDbConnection` is easy.
Example use of `IDbExecutor`:
```
-public IEnumerable<string> ReadAllAdministratorAliases(IDbExecutor dbExecutor) {
- return dbExecutor.Query<Member>("SELECT m.alias FROM members m WHERE m.is_admin = 1");
+public IEnumerable<SemanticVersion> GetAllPackageVersions(
+ string packageId,
+ IDbExecutor dbExecutor) {
+ return dbExecutor.Query<string>("SELECT p.version FROM packages p WHERE p.id = @packageId", new { packageId })
+ .Select(version => new SemanticVersion(version));
}
```
## Injecting `IDbExecutor`
You probably already have an apporach to injecting `IDbConnection` into your app that you're happy with. That same approach will probably work just as well with `IDbExecutor`.
-Personally, in my dependency container or service locator, I like to bind `IDbExecutor` to a method that instantiates a new `SqlConnection` and `SqlExecutor`. If you need to control the creation of the executor (for instance, you only need it conditionally), you could bind `Func<IDbExecutor>`. There's also an `IDbExecutorFactory` interface in `DapperWrapper` you could use, but it comes with the same downsides as any factory type.
+Personally, in my dependency container or service locator, I like to bind `IDbExecutor` to a method that instantiates a new `SqlConnection` and `SqlExecutor`. If you need to control the creation of the executor (for instance, you only need it conditionally), you could bind `Func<IDbExecutor>`. There's also an `IDbExecutorFactory` interface in DapperWrapper you could use, but it comes with the same downsides as any factory type.
Example of binding `IDbExecutor` and `IDbExecutorFactory` using Ninject:
@@ -42,4 +45,4 @@ public class DependenciesRegistrar : NinjectModule {
## Transactions
-I sometimes need to assert whether a method-under-unit-test completes a transaction via `TransactionScope`. To make this easier, `DapperWrapper` also has an `ITransactionScope` interface (and `TransactionScopeWrapper` implementation) that makes it easy to create a fake transaction, and stub (and assert on) the `Complete` method. As with `IDbExecutor`, you can bind it directly, via `Func<ITransactionScope>`.
+I sometimes need to assert whether a method-under-unit-test completes a transaction via `TransactionScope`. To make this easier, DapperWrapper also has an `ITransactionScope` interface (and `TransactionScopeWrapper` implementation) that makes it easy to create a fake transaction, and stub (and assert on) the `Complete` method. As with `IDbExecutor`, you can bind it directly, via `Func<ITransactionScope>`.

0 comments on commit d4a43c9

Please sign in to comment.