Demystifying the DbProviders in BlogEngine.NET

If you are a BlogEngine user who prefers databases, you will see a bunch of new stuff when you download the latest version, 1.4.

For the un-initiated, BlogEngine.NET makes use of the provider model to handle its blog data storage.  By default, BlogEngine uses XML for data storage and the provider implementation is simply called the XMLBlogProvider.  Since version 1.0 however, BlogEngine.NET has allowed for SQL Server to be used as a backend as well.  The provider was called, the MSSQLBlogProvider.  By making some simple changes in your web.config, you could tell BlogEngine to use one method of storage or the other. 

Additionally, BlogEngine.NET has also historically made use of the Membership and Role providers and have used an XML implementation of these.  A user could always add the settings to use the SQL Server membership and roles providers if they wanted to.

In BlogEngine.NET 1.4, the old MSSQLBlogProvider is now gone and in its place there is a shiny new DbBlogProvider.  In addition, as you look down through the web.config, you’ll notice a DbMembershipProvider, DbRoleProvider, and DbProfileProvider.  We’ve also added in the SQLMembershipProvider and SQLRoleProvider to make it easier for people to use these as well if they wish.  None of these new providers are set as the default provider, but they are there and ready to be used by the right person.

DbBlogProvider

The DbBlogProvider is an upgrade for the MSSQLBlogProvider.  There are a few main differences however.  At a basic level, it simply has more calls as the base class, BlogProvider, has more calls and supports more items to be handled by the BlogProvider.  However, beyond the additional calls, it has been changed to work with DbProviderFactories.  Basically, this means that instead of creating connections, commands, and readers using the old familiar SQLConnection, SQLCommand, and SQLDataReader objects, it is now using the DbProviderFactory classes to create these.

A simplified explanation of the DbProviderFactory is that this factory class will be responsible for creating all the needed connections, commands, parameters, and readers.  The class is created using the provider listed in your web.config.

   1: <connectionStrings>

   2:     <clear/>

   3:     <add name="LocalSqlServer" connectionString="dummy"/>

   4:     <!-- Mono complains if LocalSqlServer isn't specified -->

   5:     <add name="BlogEngine" 

   6:          connectionString="Data Source=MySQLServer;User ID=user;Password=password;persist security info=False;initial catalog=BlogEngine;" 

   7:          providerName="System.Data.SqlClient"/>

   8:     <add name="BlogEngineVistaDB" 

   9:          connectionString="Data Source=|DataDirectory|\BlogEngine.vdb3;Open Mode=NonexclusiveReadWrite" 

  10:          providerName="VistaDB.NET20"/>

  11: </connectionStrings>

As you can see above, the providerName property in these connectionString items tell us what type of connection objects will need to be used.  The DbFactoryProvider class created with the appropriate providerName will make all the connection, command, parameter, and reader objects of the desired type.

Ok, now that we have a basic understanding of the DbProviderFactory, let’s look again at the DbBlogProvider.  The DbBlogProvider is configured with a connectionString.  (There are a few other options which I’ve added to the sample below and will discuss briefly later.)

   1: <BlogEngine>

   2:     <blogProvider defaultProvider="DbBlogProvider">

   3:         <providers>

   4:             <add name="XmlBlogProvider" 

   5:                  type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>

   6:             <add name="DbBlogProvider" 

   7:                  type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" 

   8:                  connectionStringName="BlogEngine"

   9:                  tablePrefix="be_"

  10:                  parmPrefix="@" />

  11:         </providers>

  12:     </blogProvider>

  13: </BlogEngine>

In the above samples, you can see that DbBlogProvider is set to use the BlogEngine connectionString.  And the sample 1, you could see that the provider for the BlogEngine connectionString is System.Data.SqlClient.  The DbBlogProvider will make a DbProviderFactory that will make SqlClient conection, command, parameter, and data reader objects.

If you look back at the second sample, you’ll notice that the DbBlogProvider shown above has a few other options in it.  These are optional and not required by the DbBlogProvider.  (In truth, the connectionString isn’t required either as it will look for a connectionString named BlogEngine if it isn’t listed.)

The tablePrefix option is fulfilling a request that we have had from a number of users.  By default, the installation scripts will create all the BlogEngine tables that all start with “be_”.  If you want to rename your table and have them have a different or no prefix, you can do that and just tell BlogEngine in the provider options what tablePrefix to use.  If the option is not listed in your web.config, it will default to “be_”.

Secondly, we have a parmPrefix option.  All database calls made in BlogEngine.NET use parameters.  The databases I’m most familiar with use the @ sign on the front of parameters, but different databases use different characters for this.  If you wanted to use, MySql for example, you will want to change this option to use the “?” character as the parmPrefix.  Again, by default, BlogEngine will use the @ character if this option is not listed.

The DbBlogProvider is expecting certain tables and fields for storing data.  You can see the tables and fields by checking out the MSSQLSetup script in the Setup folder of your web site.  (The script works only on Microsoft SQL Server,but you can get an idea of what how the tables need to be set up by looking at it.)

DbMembershipProvider

The DbMembershipProvider is another new class with BlogEngine.NET 1.4.  It is a simple membership provider that uses the same DBProviderFactory setup that DBBlogProvider uses.  This way, you can set up a table in your database of choice and store this information there.  The DbMembershipProvider is not full featured, but works fine within BlogEngine.  Many databases already have Membership providers written for them, but it is nice to just have a simple built in BlogEngine version so you don’t need to worry about more dlls.

   1: <membership defaultProvider="DbMembershipProvider">

   2:     <providers>

   3:         <clear/>

   4:         <add name="DbMembershipProvider" 

   5:              type="BlogEngine.Core.Providers.DbMembershipProvider, BlogEngine.Core" 

   6:              passwordFormat="Hashed" 

   7:              connectionStringName="AlsVistaDB"

   8:              tablePrefix="be_"

   9:              parmPrefix="@" />

  10:     </providers>

  11: </membership>

The membership provider has the same connectionStringName, tablePrefix, and parmPrefix options as the DbBlogProvider.  The only new option is passwordFormat.  This option controls how the passwords are stored.  It can be set to Hashed or Clear.  It will default to Hashed if it is omitted.

The DbMembership Provider is look for a table called be_Users.  Here is the fields it uses:

DbRoleProvider

The DbRoleProvider much like the DbMembershipProvider is a simple RoleProvider.  It is not full featured, but works fine within BlogEngine.  It uses the the same DbProviderFactory setup and the connectionStringName, tabelPrefix, and parmPrefix options.

It uses two tables.  The first is called be_Roles.  It has 2 fields.

The other table is called, be_UserRoles.  Here are the fields it uses:

DbProfileProvider

Lastly, we have the DbProfileProvider.  Again, this is just like the others.  It uses the DbProviderFactory and the same 3 options, connectionStringName, tabelPrefix, and parmPrefix.  It has 1 table it uses called be_Profiles.

Anyway, that should should cover anything and everything you might want to know about these new providers in BlogEngine.NET 1.4.