I basically agree with OriginalGriff but would rather think that database is maybe an overkill for this simple problem. Am simple XML file with questions and answers would to the trick perfectly. Moreover, you absolutely do not need to do XML programming. Such a simple thing as
Data Contract
will do it all for you. You don't really need to work with XML; all you need is to persist your data model.
So, you first need to develop a data model of the test. It could be as simple as this: a class or structure containing: a question, a list or an array of variants for one question and a reference to a correct one. Then, you will need a list of such structure to represent a whole test.
Then, add data contract attributes to your types and relevant members, and tell Data Contract to persist it all for you. I mentioned reference before. What's good about
DataContractSerializer
, it can persist an arbitrary data graph, not just a tree (that is, it can persist a data structure with circular references without falling to a stack overflow).
Now, it only leaves for some references. Please see:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[
^].
See also my past answers on the topic:
How can I utilize XML File streamwriter and reader in my form application?[
^],
Creating property files...[
^].
[EDIT]
You also don't have to edit XML file manually, even though this is also a valid variant: you can create some "demo" instance of the data structure just once and save it programmatically; it will give a clear template for creating new versions of test demo manually. If you want to make if a bit better, you can develop a simple stand-along UI application using the same data model used exclusively to editing of the test data. If could have buttons like "Add", "Edit" (new question or edit existing question), menu items "Save" and "Open", etc.
Here is one simple technique you can use: you can have you data model in a separate library assembly to be referenced by both editing application and your "working" application or Web application, but there is nothing wrong is one project simply references the assembly of another applications. In .NET, an assembly is assembly; there is no essential difference between "DLL" and "EXE".
—SA