i have a client server application showing where the clients are intended for touch screens. The purpose is to collect data from polls, questionaires and perform interactive tasks with the client (eg. searches in database). The client is a WPF application where i from the server can push usercontrols out and have them display. So far so good.
Up until now i have not been able to expose a generic datasource from the server to the client. What i am trying to accomplish is to feed the client “something-connected-to-the-server” that allows the client to save data (e.g searches or poll results) and then query the datasource for data.
The data collected from the various controls in the client varies greatly, from question/answer to search/result – all this i would like to channel through my server. So that each client not hold its own dataconnection to a database.
Im thinking something in the line of having a table in my servers database with metadata on each clients data (types and columns) and then a simple table for storing the data.
Any ideas on this or alternative approaches?
How much data are we talking about?
My first suggestion, but this might not align well with your API, is to use the command design pattern to send and receive data. This allows the flexibility of adding or changing functionality without having to change your communication layer, especially if you are able to load new commands through plug-ins. However, it is unlikely that would work well for plug-ins made by the client.
For smaller amounts of data, would it be feasible to let the client create a CSV or XML file, store it on the server, and request a copy of it when needed? You could then load this into a DataTable or similar structure to run queries against on the client. You could store any changes that were made to the data and send it back to the server when the client is done with it. The benefit of this is that the client is able specify the data they want and how they want to store it and the server components don’t care.
For larger amounts of data…no idea. I have experience with creating meta-data tables and creating the tables they describe and building a querying framework on top of that, but I doubt that is the best solution. Things tend to get messy fast — look-up tables, many-to-many relationships, cascading look-up tables, hierarchies, etc. I’d carefully think about the kinds of data requirements you will have before you go this route.
If you aren’t constrained to SQL for the data, you might consider using something like RavenDB (or other NoSQL solution) to store their data. As long as they can serialize the objects to send to your server, you can store them in the database. Sending queries to the server might be a problem (I don’t know for sure though).