Synch Framework & Multi-Tier applications

I've used ADO.NET synchronization framework in an internal project and had to give a presentation about it in the local Visual Studio 2008 Launch.

I'm quite impressed with it and with the whole MS synchronization story. The usual demo basically implies changing one line of code and adding three more to switch from an application working locally with SQL Server to one that uses SQL Compact Edition and synchronizes itself.

Using a local SQL Compact Edition database and ADO.NET Synchronization is a very interesting architecture for smart clients.

The fact that you are in a two tier world and you can use LinQ (to SQL, to Entities, etc.) to talk directly to SQL Compact Edition greatly simplifies your code. You don't have to worry about having a coarse-grained service layer, and you can avoid working hard on optimizing the number of roundtrips between the client layer and the domain layer.

Of course, there's the issue of synchronization itself, but the Synch Framework is quite good at it. Handling conflicts is usually challenging but the framework does not add significant accidental complexity to the process, and handling conflicts is a part of every application even if it's an online application. You can do a "last one wins" or have some kind of conflict resolution mechanism based on previous values or timestamps.

Actually, living in a two tier world was one of the reasons that made web development popular. Is was much more easier than building three tier apps.

The fun thing is that we are back in a three tier world. AJAX and Silverlight/Flash applications are three tier, so the shortcuts that we took in web development are not allowed anymore. We need to have a coarse grained service layer to work efficiently.

Or not. I guess it's not far the day where we could use SQL Compact Edition from browser-hosted applications.

I'm not saying it's a solution to every problem, but it can probably be applied to many scenarios.