I think I have mentioned it a little bit about it in the past, but I haven't ever really blogged about it. So here goes. ChiroEase is the side-project that I have spent a decent amount of my nights and weekends on for the last year or so.

The basic idea is that ChiroEase is a smart-client application for managing a chiropractors office. Currently there are a large number of older applications available for chiropractors, many are classic windows applications, many are actually geared toward all medical professions (so they include lots of unused features), etc. There are some new good competitors out there, but I think the one angle we have is that we are really trying to make it as simple and easy to use as possible. Because it's a smart-client they don't have to worry about back-ups, they can access the data from multiple devices, access their data from home, etc.

I never thought I would be building a smart-client. I think 99% of the time a website does a better job than a smart-client, but there were a couple compelling reasons to build it this way. The main reason for this is if the office's internet connection goes down they need to be able to continue using their office. Internet connections don't go down that much anymore, but the other partners saw it as a big issue from a sales standpoint. The second reason is that the people using these tools aren't usually savvy computer users. They are used to working with a windows app and this makes the transition much easier. We have plans for putting out a web-only version after we are done with the smart-client, but it will be in addition to and not instead of the smart-cleint.

Enough about that though, the more interesting part to me (and probably you) is the architecture. Here is what I came up with.

The Server-side is fairly simple. There is a web services front-end to a business logic layer. I use strongly-typed business entities (POCOs) tied up to NHibernate. There is a little data layer for the things that can't be done through NHibernate that talks to SQL Server 2000. This works fairly well, I have MbUnit tests at the business and data layer levels. One change I would like to make is to switch to MonoRail's ActiveRecord but for the time being I am using plain old nHibernate. Another change I would like to make is to use Rhino.Mocks for testing, but right now all of my tests hit the actual database.

The client-side is a little trickier. Since the application is a smart-client it needs to be available on-line and off-line. I looked at using SQL Express, but the install and uber-fat package scared me away. I decided on SQLite as off-line storage. This was before SQL Compact was available so I didn't compare SQLite with that. I have been incredibly impressed with SQLite. I used System.Data.Sqlite in conjunction with NHibernate. One of the more interesting parts of this is that I actually use the exact same nHibernate files and data access code on the server-side and client-side, which I think it just pretty cool.

The other client-side decision I had to make was what smart-client model I wanted to go with. I could go with either a sync model where the client and server-side database would synchronize when coming on-line, or I could go with the queue model where I store messages in a queue and send them when the connection comes back on. While making this decision the Smart Client literature over at P&P was very helpful, unfortunately when I went to look at the Smart Client App Block I found it to be over engineered and overly complex. Instead I just grabbed the only code out of the block I felt I really needed (the PInvoke line to check for a connection) and wrote my own simple message based queue. Basically when I try to send a message and the connection is down I store that message in Sqlite. When the connection comes back up I send those messages. The only tricky part is dealing with any concurrency issues that might have occurred, but from a day-to-day standpoint the user shouldn't have to deal with that very often.

For the actual client-side piece I used Windows Forms (just regular not XAML) with the Developer Express library. I didn't want to deal with the crappy default controls, and Developer Express gave me a free license for being an MVP, so I went with them. Their library is comprehensive and very well done. The couple of issues I have come across have been quickly answered by their support or I have found an answer in the docs. The only thing lacking was a wizard control, and I went with ActiPro for that. It works OK, but it has some hard to troubleshoot issue where it grabs an assembly and won't let go. (very frustrating as it means you have to reboot Visual Studio). For the actual architecture of the client-side I went with the obscure Presentation Model pattern. Most people use MVC or MVP, but I have become pretty fond of the presentation model. I am writing the synchronize logic by hand, but I think in the future I might try to whip up a framework to do that for me. If you aren't familiar with it, take a moment to read up on in from Fowler. The main reason to use the presentation model is that I think it works great for testing your presentation logic and it eliminates the pointless interfaces required for MVP.

That's about it really. We are dangerously close to a beta of the product, but we hit a snag when we lost one of our main subject matter experts. My two partners on the project (a business/project manager and a chiropractor/sales guy) are busy trying to find us some new users and then we should be ready to go. My goal is to have it live and running by the end of the year, which is a little ambitious but not out of the question.

-James