问题
Hope you can help me get on the right path. I am currently in Design phase of my project. I have a WCF Soap/Rest Web Service that will be consumed by my WPF Client Application. Since the WPF Application needs to work on both Connected and Disconnected State I am having a design problem of how to implement caching.
I am aware of caching during the runtime of the application using ObjectCache but I am wondering in case of the application being closed and re-opened I would like to retrieve anything that the user has already entered as well if the user is disconnected that I can grab last Web Service Response and populate the form? Since ObjectCaching is only while application is up, one way I thought is to have a local database where the client app stores all the data from web service response and user entered/modified data. What I don't like about this option is that I have to duplicate the server database and its tables and data which I don't think is very good practice as well very secure.
Finally, how do you sync all the data? While being disconnected when your finally connected I need to call the WCF Web Service update method and update information back to server. Would this be some type of messaging with a batch job that would run on the client that would know when your connected and reprocess all the data? Any thoughts would be great.
回答1:
What you're looking for is pretty easy to accomplish, and doesn't require a client-side database. Whether you implement it this way really depends on how secure you need the data to be.
To persist data on the client in a totally disconnected way that lets the user exit and return with no risk of losing their entries, your only option is to store the data on the client. If the application is not able to access the web server to persist the changes, and the application closes or crashes, the changes are lost, and the user is unhappy.
To make this work, create a serializable class or classes that fit your client-side field requirements. The classes need to implement INotifyPropertyChanged so you can bind your UI fields to it and keep the changes inside of the model object (as opposed to the UI controls themselves). Your code behind also needs to implement INotifyPropertyChanged. You need a property that holds the instance of the data object, and this is what you bind your fields to.
As the user types/makes changes, your data bindings have 3 update options: update the property when the user leaves the field, update the property as the text changes, or wait to update the property until after a specified delay time. When these updates occur, the PropertyChanged event is raised. If you attach to this event, you can write a method inside the class to serialize it and save the data as it is entered. A simple XML or JSON file is fine. You also need to add a load method to read the data file, deserialize it, and return the data object. This way, if the application were to close or crash unexpectedly, you would simply call the Load method and set the property in your code behind to the loaded object, the bindings restore the text, and the user can continue.
To keep everything synchronized, the client sends the object to the server so it can validate and save the changes. I would use a field to track data versions (TimeStamp field if using SQL Server) to prevent a client with outdated data from overwriting newer data, especially if you're in a multi-user environment.
If your server is able to take advantage of WCF and Entity Framework, you can build a very robust, reliable application very quickly.
As far as security goes, that depends on the type of data being entered and the legal requirements behind them (I.e. Credit cards and PCI compliance), so you would have to address those individually.
来源：https://stackoverflow.com/questions/27257609/generating-occasionally-disconnected-wpf-app