Introduction (i.e. What was I thinking …?)
With the advent of the .NET platform, there’s been huge interest in the area of Smart Client applications. While the concepts behind them have existed in pre-.NET days and in non-Microsoft platforms, never has this technology looked more promising than it is today. From WinForms 2.0, WSE 3.0, Composite UI Application Block etc. all the way to WCF and WPF, Microsoft has made sure that if you want to go Smart-Clienting, MS tools are the way to go. Nearly 6 months ago, I got the chance to work on my company’s first ever Smart Client application. Needless to say, being a very successful web development company, it was looked at as high risk - high reward project. If we made it work, we’d have opened up a whole new market; if we did not, it would’ve been back to the old game plan (at least for a while).
So we played it safe; stuck to the recommended application blocks, most stable releases of the development tools etc. etc. Surprisingly enough, we managed to put together our first prototype in record time, using .NET 1.1, 2005 and 2004 releases of MS DAAB (Data Access Application Block) and SOAB (Smart-Client Offline Application Block) and WSE 2.0 SP 3.
This gave us the chance to take a long look at our next milestones. Which were basically, migrate to VS 2005, ditch DIME for MTOM, adopt the new (.NET 2.0) & truly asynchronous remote invocation model and of course migrate the existing application blocks. While rest of the transition was pretty smooth, we never found a new version of the offline application block. I have to say, we never really liked the original SOAB to begin with. It lacked a lot of the functionality we required but came in a huge bundle linking to the DAAB, Caching Application Block, Exception Management Application Block etc. etc. Nearly 140 source code files! Doesn’t make your life any easier when the application starts crashing for no apparent reason…
And by the way, deploying an SQL Server on client machines? Oh, come on! Whatever happened to X-Copy Deployment? Of course, there are other options for storage, but they are hardly worth talking about.
So, it got me thinking. There had to be a better way; and there was.
Db4O – 4 All Your Offline Needs
Now, if you take Microsoft’s Offline Application Block, it serializes the cache objects and command queue items on to its database. Once you do that, you loose lot of flexibility. Of course in the RDBMS world, there’s hardly any alternative. In the MSDE world, there was no way to design a Cache database or a Queue database to hold arbitrary application specific objects. But, with SQL 2005, I’d assume you could use XML columns and along with XQuery to achieve this. Then again, even if you do it, I can still whine about the X-Copy, right?
Last year, while researching for my final year project, I took a look at Db4O (http://www.db4o.com/). Db4O is an open-source, object database for .NET/MONO and Java. See, sometimes education does come in handy. I was just playing with the idea of using the object database for the cache/queue database, and it didn’t took 5 minutes before the advantages became evident. The downside is of course, Db4O is distributed under GPL and if you need to use it in a commercial application, you’d need to get a commercial license from the developers.
So hopefully, over the few days, I’d post more details about the Offline Application Block that I have developed. And by Monday, if I could get my code refactored properly and figure out the licensing issues, I’d have the full source code available for you.
