SaveAnOrder()
–>This calls a facade
→ the domain facade calls a sql helper class which uses Dapper ORM to
save the order to the db
Finally raise an “OrderCreated” Event
Questions
From what I have read about the Outbox pattern, the same transaction and connection should be used between the dapper ORM and Outbox, if this the case, what are my options to enable outbox here
a) should i send the context context.SynchronizedStorageSession.MyPersistenceSession(), to my
the façade layer which will in turn send it into the SQL Dapper class and use the connection and
transaction object?
the problem with the above approach is that
my façade class and ORM class is taking a dependency on the NserviceBus,
assuming even if were to convince everybody, how are we going to mock the the
context.SynchronizedStorageSession.MyPersistenceSession() in unit tests.
And how do we pass this dependency during my ORM integration tests ?
Can we use ASB transport along with SQL persistence outbox ? or does it have to SQL transport
and SQL persistence ?
Does SQLPersistence support Azure Managed Identity ?
Can we dispose the connection and transaction (using statement) that we get from the context.SynchronizedStorageSession.MyPersistenceSession() ?, basically dapper methods are extension methods on the connection object ?
I could only find EntityFramework ORM examples, any pointers on how we can accomplish the same thing with dapper ? any example would be really helpful.
Yes, that is possible. The outbox requires the same storage as persistence but the transport can be different.
I’ll look into this and get back to you.
No, you should not dispose these as the lifetime of these is controlled by NServiceBus. You don’t own the objects (injected) thus not dispose them.
Take a look at this example. It should how to obtain transaction information, initialize a helper object in a pipeline behavior and have this injected via DI in the resolved object graph.
You should just assign the connection its AccessToken property:
var accessToken = FetchAccessToken(); // Must fetch the Azure Managed Identity access token
var persistence = endpointConfiguration.UsePersistence<SqlPersistence>();
persistence.ConnectionBuilder(
connectionBuilder: () =>
{
var conn = new SqlConnection("Data Source=<AZURE-SQL-SERVERNAME>; Initial Catalog=<DATABASE>;");
conn.AccessToken = accessToken; // Assign token in addition to creating the connection.
return conn;
});
The transaction that you would retrieve via the mentioned sample is managed by NServiceBus. Meaning, it is shared. You should not commit or roll back this transaction or close the connection.
In general you should not catch errors yourself and rollback transactions as this would conflicht with the recoverability mechanism from NServiceBus.
I think it would also be good to few the following guidance on transactions and recoverability: