Second Year Software Engineering student here. I want to make a file managing system for a C# notetaking app, every note will be represented by a file and will display a small preview of it, furthermore all notes should be query-able, rearrangeable and editable, the whole system it self should be portable to other platforms too.

I had to drop a simple implementation based on the file system although it might be simple and reliable, querying, editing and previewing all have to be done through the OS it self and then updated into the UI, making the app more depended and rooted to its platform, loading up the entire file is not that recourse friendly either (there is always storage.getfilesAsync but it don't provide much more than a list of paths)

The next logic step was to look at SQLite, while it surely has all the managing tools I wanted it kinda feels like an overkill and is a third party solution so I don’t get into all the fuzz installing it and tuning it, I thought there should a simpler built in alternative to it.

So Looked into Implementing a Directory file on XML, my idea was to put a small preview of the Note on each element, the file path that represented it and misc metadata like date. This way I would just load up my directory file that has all the Previews and addresses on it and It would just open each file dynamically based on its saved path when the user wanted it.

This implementation looks almost perfect to me:

• Its lightweight in terms of resource use,

• The xml can be ported and send to other platforms easily providing a backbone of my file system to other platforms

• Its a very simple built-in one file solution compared to sqlite.

To top this all up, C# has LinQ, it allows the user to treat the XML file like if it was a database, it pretty much gives the ability to write sql queries against it, which to me looks pretty awesome and incredible useful for my usecase.

But, I like to question everything, and its part of the reason why im here, please tell me what you think about this implementation:

  • Are there any pitfalls?
  • Is there an even better way than this ?
  • Are implementations like this an often sight in the Industry ?
  • 1
    The whole point of the System.IO namespace is to provide a layer between C# and the underlying system. Trying to replicate the filesystem with a second dataset is asking for stale data problems.
    – Caleth
    Sep 4, 2017 at 9:41
  • @Caleth yeah, id stick with that if i dint want to keep metadata and a preview, opening up a stream against hundreds of io. files just to get a few lines of data doesnt sound right to me. Sep 4, 2017 at 12:02
  • You don't need to do it all in one go. You can load the metadata (once) at the point where you need it (first) for each file
    – Caleth
    Sep 4, 2017 at 12:05
  • @Caleth good suggestion, i thought about it a bit more and i will just append the metadata on the filename, this way i can fast receive both the path of the folder and its metadata with the StorageFolder.getfilesAsync() without actually opening streams against them and wasting cpu and ram. Sep 4, 2017 at 12:26

1 Answer 1


I figured it out, i was over complicating the whole thing, i will just append the metadata on the filename, this way when i call StorageFolder.GetfilesAsync() i will get all the folder-paths and then extract the metadata from them, best part is that This getfoldersasync Function does not open up a stream against them.

After that i can always save them to an IENUMARABLE list that can be easily turned into xml that will be used for cross server/platform comms

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.