views:

262

answers:

6

Take a .Net Winforms App.. mix in a flakey wireless network connection, stir with a few users who like to simply pull the blue plug out occasionally and for good measure, add a Systems Admin that decides to reboot the SQL server box without warning now and again just to keep everyone on their toes.

What are the suggestions and strategies for handling this sort of scenario in respect to :

  • Error Handling - for example, do you wrap every call to the server with a Try/Catch or do you rely on some form of Generic Error Handling to manage this? If so what does it look like?

  • Application Management - for example, do you disable the app and not allow users to interact with it until a connection is detected again? What would you do?

A: 

In our application, we give the user the option to connect to another server, e.g., if the database connection fails, a dialog box displays saying that the server is unavailable, and they could input another IP address to try.

Jon Limjap
+1  A: 

We have this in our Main() method which traps all unhandled exceptions...

Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(UnhandledExceptionCatcher);

Thread.GetDomain().UnhandledException += new UnhandledExceptionEventHandler(Application_UnhandledException);

and then Application_UnhandledException and UnhandledExceptionCatcher display user friendly messages.

In addition the application then emails data such as the stack trace to the developers which can be very useful.

It depends on the app of course but for the kind of failures that you describe I would close the app down.

Si Keep
+2  A: 

I have not touched WinForms and .NET for years now, so I can not give you any technical details, but there is the lager picture answer:

First and foremost - do not bind your form data directly to a database.

Create a separate data/model layer that you bind your form widgets to.

From there on, you have several options available to you depending on the level of stability and availability you need to provide.

Probably one of the simplest solutions here would be to just enable/disable the parts of application that need to interact with a database based on the connection state.

Next level of protection would include caching the part of the data model locally and while the database connection is down, using local cache for viewing and disabling any functions that require explicit database connection.

Probably the trickiest thing (that may also provide the most stable experience to the end user) is to replicate the database locally and use some sort of synchronization schema to keep your copy of the database in sync with remote db.

Roland Tepp
+1  A: 

This may be a little too much support for the offline scenario, but have you considered the "Microsoft Sync Framework"? Included in the framework is the "Sync Services for ADO.NET 2.0", which allows your application to hit a local SQL Server CE instance. This can easily be synchronized with a central SQL Server via a variety of methods.

This framework handles the permanent offline scenario, and as I said, it may not be appropriate for your specific requirements, however it will give your application solid offline support.

Brad Leach
+3  A: 

Answer depends on type of your application. There are applications that can work offline - Microsoft Outlook for example. Such applications doesn't treat connectivity exceptions as critical, they can save your work locally and synchronize it later. Another applications such as online games will treat communication problem as critical exception and will quit if connection gets lost.

As of error handling, I think that you should control exceptions on all layers rather than relying on some general exception handling piece of code. Your business layer should understand what happened on lower layer (data access layer in our case) and respond correspondingly. Connection lost should not be treated as unexpected exception in my opinion. For good practices of exceptions management I recommend to take a look at Exception Handling Application Block.

Concerning application behavior, you should answer yourself on the following question "Does my application have business value for customer in disconnected state?" In many cases it would be beneficial to end user to be able to continues their work in disconnected state. However such behavior tremendously hard to implement.

Especially for your scenario Microsoft developed Disconnected Service Agent Application Block

aku
A: 

Use something like SQLite to store data offline until a connection is available.

Update: I believe SQLite is the back end for Google Gears, which from my understanding does what you're looking for in web apps... though I don't know if it can be used in a non web context.

Giovanni Galbo