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 Hanselman 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