Reputation: 12331
I'm starting a new project and I've a constraint about data. Basically, the "data" is actually a bunch of files organized in a well-defined hierarchy.
The client wants to be able to access these files using the Windows file explorer while also load the data in a program to obtain a refined view of the information. This program would load the files, parse them and extract the required information. It should be able to perform some kind of querying against the files (last date of modification, size, all the files of a certain kind)
My problem is to be able to marry those two views.
My first idea was to back up the file system with a database holding the paths and some metadata concerning the files... But I was wandering if there was any kind of filesystem abstraction to achieve this kind of thing? or a document-based db I could use ?
Basically I'd like to deal as little as possible with filesystem (but maybe I shouldn't)
hope this is not too vague... thanks.
Upvotes: 1
Views: 115
Reputation: 4632
Sounds more like an architectural problem to me.
I suggest using an abstraction layer between your presentation layer and the data sources to avoid coupling to the actual files. Establish a common interface for both the file access and database access. You application should not need to know if it is handling with the files or database data, or even some other source that might be needed in future changes. Implementing repository design pattern should be useful here.
Also, I suggest using generic data access objects that are completely independent of the underlying file/ database structure, which would allow you to experiment with different ways of data access without having to touch the application itself, too.
As for document oriented database, I do not have experience in this field. But RavenDb, for example, is a popular open source product that has .NET support available out-of-the-box, and is worth a look.
Thinking about the double-access with application as well as via Windows Explorer, you might want consider using a FileSystemWatcher to check if any files were changed and then update the corresponding database entries with the changed contents.
If this is a useable approach, of course, depends very strongly on how often the data will be changed. If the files are edited too often this might overburden the DB access. You should check out possible performance impacts early on.
For other ideas we would likely need more information. But at least these thoughts might give you a starting point.
Upvotes: 2