Is anyone using the Sync Framework in CSLA to make an offline application? I'm looking for examples of how I would implement this. Any help or suggestions would be awesome!
It would be cool to see an offline mode for CSLA that would make using disconnected apps easier.
We haven't used the MS Sync framework, but instead have a home grown version that loosely based on its architecture. With our current products the CSLA business objects know only about the local SQL CE database. The sync process is handled on a background thread.
The app startup process configures the sync engine to which tables need synchronized and then starts a timer. When the timer fires it first checks to see if the SQL server is available then kicks off the sync.
We plan to switch the MS Sync framework as soon as a possible, because in our version we didn't support all the upload/download/snapshot scenarios.
Rick...
This is probably not the answer people were hoping for, but...
I looked into this a while ago - back when they had first introduced it for use. I've looked at the VS 2008 version, which doesn't seem to be much different, save for the IDE integration. In any event, I ended up not using it, largely because my requirements moved on me. As such, I don't have the code anymore.
It is my belief that if you try to use the VS 2008 IDE integration to get the job done, you're not going to be happy - largely because you're going to have to expose too much of the gunky details to your BO's. This kind of thing is a perfect candidate to be wrapped up in a DAL - and that's what I did. The idea behind the sync framework is to use SQL CE to mirror your database on the client side, and let the framework largely handle the details from there. If you wrap all this in your DAL, then your BO's don't have to know any different. And that's how you want it, because then it doesn't change anything about how you code your BO's.
Within the DAL, you can save the data to the local data store, and then fire off the sync updates if you can. And if you want to fire off your sync updates at regular intervals with a timer/background thread, you can certainly do that through code in your DAL. Yes, you have to expose that to your application, but that's a fairly minimal exposure - basically it's a "Start" method your app calls upon startup, and a "Stop" method you call when it shuts down. To eliminate the direct DAL reference, you can provide a facade within your business layer.
The one thing I haven't considered is how you might work this within a LINQ/EF concept. I don't have a lot of knowledge about those yet, but it would seem to me that you can utilize them just fine - just build your metadata objects off the SQL CE database instead of your server database. SQL CE doesn't support stored procedures, so the SQL-based solution LINQ/EF provides fits in rather nicely. Then you can let LINQ/EF manage the updates to the client database, and the Sync Framework manage the sync to the server.
Just MHO...
- Scott
Even me am thinking on the solution and have done nothing so far. But my worry is that while the SQL CE is local ( In the client machine ) DAL is executed in the Server acting on the objects data
Not if you use a local DataPortal. Then it's all on the client machine.
If you're working in an n-tier situation, then you still can make this work. You just change your middle tier to host the the server side of the Sync Framework instead of your remote DataPortal, you move your DataPortal to run locally, and you use the remote proxy concept they provide for the server process. And you can still encapsulate all this within your DAL - which runs on the client machine. Your DAL writes to the local SQL CE database, and it still can either immediately sync to the server, or let your background process take care of it. Either situation interacts with the proxy to the remote Sync server component. You host that server-side syncronization piece just like you'd host a remote DataPortal.
- Scott
Copyright (c) Marimer LLC