Correct way for storing data for runtime use in stand-alone applications?

Question

I am working on a project that involves a "team builder" type application, if you will using C#.

For the sake of simplicity, let us say it involves the user creating a "Team." There are three teams to choose from.

Each team has "positions," for example, such as Captain, Shooter and Runner.

Each Captain has 3 possible choices, with different attributes such as "Name", "Skill" and "Age".

To give more of a visual representation of this:

• Team1
• =>CaptainATeam1
• ===>Name
• ===>Skill

• ===>Age

• =>CaptainBTeam1

• ===>Name
• ===>Skill

• ===>Age

• =>CaptaniCTeam1

• ===>Name
• ===>Skill

• ===>Age

• Team2

• =>CaptainATeam2
• ===>Name
• ===>Skill

• ===>Age

• =>CaptainBTeam2

• ===>Name
• ===>Skill

• ===>Age

• =>CaptaniCTeam2

• ===>Name
• ===>Skill
• ===>Age

Now, all of these attributes would be predefined and never change. So, CaptainATeam1 will ALWAYS be "James", "Skillful", "22".

With all of that being said, this information would need to there for run-time usage. This application would not be connected to any type of database of some sort, and would run strictly as a stand alone application.

My question is what is the correct way to go about doing this?

The current thought I have is storing the data in a package with the application in the form of a flat-file for each team and position and having the application read them to memory at run time when needed.

But I have also considered creating the datasets within individual classes as well, with something similar to this (not tested and written quickly on Notepad, but the concept is there):

class Team1


var Captain;
var Shooter;
var Runner;

DataSet ds_team1 = new DataSet();
//used to populate a dataset to be used for a DropDown style selection list
public void PopulateCaptains()

{
DataTable dt_caps = new DataTable("Capitans");

dt_caps.Columns.Add("Name");
dt_caps.Columns.Add("Skill");
dt_caps.Columns.Add("Age");


DataRow dr_cap1 = new DataRow("Cap1");
DataRow dr_cap2 = new DataRow("Cap2");
DataRow dr_cap3 = new DataRow("Cap3");

dt_caps.Rows.Add(dr_cap1);
dt_caps.Rows.Add(dr_cap2);
dt_caps.Rows.Add(dr_cap1);

dr_cap1["Name"] = "James";
dr_cap1["Skill"] = "Skillfull";
dr_cap1["Age"] = "22";

//so on and so forth.

}

Obviously the example above would be very cumbersome coding wise as opposed to just writing a foreach loop through flat files stored in the application's folder. However, that allows for the user to manipulate information in this file, causing the program to break.

So, what would be the correct approach to dealing with this?

IS there a correct way for dealing with this?

Note If this is considered way too much of a subjective or broad question, please let me know so I can either go look for more information, provide more information, or clarify anything.

Thank you for you time.

Answer 1

First of all, I think your code is decent and readable. A couple of things that I see wrong with this implementation here:

1. You're implicitly defining variables using the var in the global space. I would suggest changing these to their actual types. var is reserved for local implicit definitions, and actually this won't compile. See this question for a more elaborate explanation on this.

2. What you're doing is hard-coding the data into your program. You want to avoid this whenever possible. XML or JSON serialization/de-serialization will do the trick, and you won't need a database to achieve it. You may decide someday that you actually would like to use this data in a database. Or, down the road you may decide that you want to use this same data in a different application. So in either of these two events, by doing serialization you will make this process 10-times easier. See XML serialization or JSON serialization.

Hope this helps.

Answer 2

You have several choices which are based on your needs.

1. You can hard code the data. This is done quite often in unit/integration tests and is a valid way of storing this data. It makes it quite difficult to change, especially for a BA/non-developer.
2. You can store it in a file of some sort. The format could be JSON or XML or CSV if you like. If you want to prevent modification of this file you can add a checksum check against it and break if the checksum is different.
3. You could store it in a database. SQL Lite would be a good choice for this. It's lightweight, fast and doesn't require a huge cumbersome install like Oracle or SQL Server. If the data may need to change over time then I would recommend this option.

Remember that today's prototype is tomorrow's production code. Just because you think you won't need to change the data doesn't mean you won't have to change the data. You almost certainly will. Whatever solution you choose, you will likely be stuck with for some time, so pick carefully.