This post originated from an RSS feed registered with .NET Buzz by Brendan Tompkins. Original Post: Refactoring WSMQ - Provider Patterns, DAAB and CodeSmith Feed Title: Brendan Tompkins Feed URL: /error.htm?aspxerrorpath=/blogs/brendan.tompkins/Rss.aspx Feed Description: Blog First. Ask Questions Later. Latest .NET Buzz Posts Latest .NET Buzz Posts by Brendan Tompkins Latest Posts From Brendan Tompkins

Now that CodeBetter.Com is humming along fairly nicely, I’ve been turning my extra time (much to my wife’s chagrin) to my pet project, WSMQ.

If you’re not familiar with WSMQ, it’s a simple queueing application that supports multiple backend data storage mechanisms  (currently SQL Server, and file-based XML) that can be accessed over different endpoints.  The beta currently supports WSE 2.0 Web Services access over HTTP, but the next version will include support for REST, soap.tcp and direct dll project integration.

I received some really good feedback after the first beta, specifically, around the back-end data storage scheme.  The original version was built to support XML, and the SQL Version was quickly put together knowing that refactoring would be the next step.

The first beta version had the following drawbacks:

• DataSets were used to shuttle data between the database and the business entities.  The extra overhead of datasets was un-necessary.  I’m with Scott Hansleman on this one.
• The data layer was a concrete class, and there was dependent code in the Queue provider to this class.  This was a violation of the Dependency Inversion Principle, and resulted in a much too tightly coupled design.
• The data model required deletes and inserts when messages were received. This was done since it most closely mirrored the way the XML version works, and could be put together quickly.  It was very slow.
• The data layer used SqlTypes, which made switching data providers difficult.

I started with a completely new database design, which is much much better and probably very close to the version that will ship when I actually release this thing.  I re factored the code and came up with, I feel, are good solutions to each of these issues:

No more DataSets!  Whahoo!

DataSets have their place, but not in an application designed for performance.  If performance is what you’re after, it’s DataReaders all the way. I was definitely mis-using them in my original design.  I was getting the data from SQL, filling datasets using a DataAdapter, and then moving the data into my business tier.  My new design uses the Data Access Application Block, returns DataReaders, and fills the business objects from the readers. This has resulted in an enormous perf increase.

Added a Provider Pattern for the Data Layer

The new version uses a provider model to access the Data Tier. 

See this MSDN article here for more on the Provider Pattern from Rob Howard

[The Provider Pattern is] a pattern that allows for a pluggable Business Logic Layer (BLL) and Data Access Layer (DAL) for published APIs. This pattern is being used throughout the new ASP.NET 2.0 infrastructure features; it allows you to unplug our default implementation of an API and plug-in your own—a very powerful capability.

In fact, Rob created some CodeSmith templates, that will create your abstract and concrete Provider classes for you.

Provider Model Templates (using MS DAAB) :: CodeSmith Peer Support Forum

The attached template creates the Configuration, Abstract, and Concrete classes you will need to implement a SqlDataProvider for your projects. You can alter these templates to use any of the other DAABs out there (GotDotNet, etc) if you want to create an Oracle, Access, MySQL, etc provider.

I’ve modified his templates to use the new DAAB from the June Enterprise Library, and to be database-agnostic using only the abstract db types.  You can download my templates from his thread on the CodeSmith support forum. The result is that the entire data layer can be swapped out, by simply implementing an interface, dropping a DLL and making a configuration change.  Can’t get much more pluggable than that.

I’m also adding a Provider model for the queue provider itself, which will let you plug in a custom provider to handle the entire back-end queueing operation.  This will allow you to plug the WSMQ front-end service, web management tools, etc to any queueing application, such as MSMQ or WebSphere Queue.

I’m very happy with the way this is all coming together.  I’m going to be releasing beta 2 in the next couple of weeks, and hopefully will be able to release version 1 around or just after PDC… Beta 2 will be an open beta (no registration) so look for that soon.

-Brendan