Which .NET data storage technology: Data access local only and web service based
I'm just starting with .NET data storage and I'm confused by so many different technologies... This is a learning project. You don't need to go on reading, I need to make an architecture proposal first... Thanks so far
e.g. a local app that can store and tag images. The user can choose if he want to
- store his data local only
- web based only
- or a mix of both
- No additional local db server installation
- The user can upload selected parts of his local data to make it public available for other users
- Other users can add this data to their local repository
- Later there should be the capability that so. acknowledges the upload before it is pubic available => WWF
As you can see many operations and data (transfer) objects are redundant no matter if the operation is local or web based. This is one of my main goals to make use out of this fact. I'm looking for programming comfort :)
I'm interested in:
Cloud could be an option but I would prefer a wcf service to access data (at least I think that I prefer this :)
Technologies I saw: XLinq, Entity framework, hibernate, Linq to ..., WCF Data services, SQLite with Linq, web services, Entity SQL... what a hell
I read much about this topic but it is hard to estimate the consequense of architectural decisions. Also other posts didn't help me on planning the project.
You make my day if you could point me in the right direction. THANKS!!!
You may want to consider SQL Server 2008 on the server and SQL Server Compact on the local machine. Each is optimised for that kind of environment, and the data storage and management features that they offer are quite similar. Abstracting out access mechanism from your code, as jasper suggests, should be extremely easy with this pair of technologies.
SQL Server Compact is an embedded database engine that runs in-process with your app, installs together with it as a "single DLL", and does not need a separate database server installation.
In any case, I totally agree with jasper that you should focus on the architecture and design on the system, and think of technology as something secondary.
your main focus imo, should be to abstract your storage solution from your storage mechanism.
Decide what methods you'll need SaveData,LoadData,GetSavedDataList,DeleteItem ... then create an interface IStorage. This way, you can write a number of different solutions, local+binary/remote+WCF, but keep the core of your application logic decoupled from the storage solution. your core logic shouldnt care where it saves/loads the information from.
Really, what storage solution you use, is up to you. Each have their own pros and cons, and its impossible for anyone to give you a 100% correct answer on which will be the best for you. In the end of the day, you're going to end up with 3 main pieces of work. Storing the data locally, transfering the data to a remote server, storing the data in the remote location.
Storing it locally could be as simple as keeping an XML file for metadata, and binary files for the images. You say you dont want to install a local DB, is this a DB engine, or any DB solution, would it be possible to use something like MsAccess/SQL CE etc, as it would make the overall design a little better?
For your remote storage, you could write a webservice that transfers an object, with the image data, and tags etc, your local system wouldnt have to know any different if you design your code well with good abstraction/decoupling, and have the webservice(on the server side), persist the data to a database using LINQ.
There are many ways to skin this cat, no doubt you'll get plenty of other advice from the rest of the SO community.