Database Reference
In-Depth Information
The SQL Server example
One of the many benefits of using SQL Server to persist sagas, timeouts, logging, and mes-
sages is that Visual Studio has many capabilities if it's used in EF, such as wizards to create
mapped objects from existing tables. So, when NSB is saving messages, sagas, timeouts,
logging, and other NSB artifacts to SQL database tables, EF can be used in console applic-
ations to monitor these artifacts. We will look at monitoring messages, and we'll choose EF
for these examples because of its ease of mapping in Visual Studio from existing SQL
Servers. EF will generate the models from existing tables that NSB creates.
Let's start by building a simple publish or subscribe example from
https://github.com/Par-
ticular/NServiceBus.Msmq.Samples/tree/master/PubSub
.
We have already walked through
this in the previous example, so we will discuss just modifying the sample to save data in
SQL databases to time. We will send the messages and subscription information to the
nservicebus
SQL database using NHibernate. This will be our
PubSub-SQL
solution.
This example will populate the SQL
nservicebus
database with the messages and sub-
scription information from the original PubSub example by changing the transport type to
SQL Server in the IBus configuration, that is,
.UseTransport<SqlServer>()
. Also,
we will change the subscription persistence type to NHibernate. The
app.config
file
will have to contain the connection information to point to the appropriate SQL Server
database. We can study some articles from
http://docs.particular.net/nservicebus/relational-
publish-subscribe-configuration
to change the configurations to send the messages and map
the subscriptions in SQL Server.
This will still be a PubSub example, except now the queues will be in the
nservicebus
database for the
MyPublisher
,
Subscriber1
, and
Subscriber2
tables.
