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");


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


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.

  • 2
    This may be a disappointing answer but: Whatever works for your needs.
    – MetaFight
    May 9, 2016 at 0:34
  • If you find parsing flat files easy, why not put the flat file contents into a string, in the package, and then parse the string? May 9, 2016 at 0:55
  • Should the data always be the same? Or should there be a way to change it (before runtime)? May 9, 2016 at 9:57
  • @MetaFight Not disappointing at all. I just was wondering if there really was a "right" way to do it. As I learn more and more about programming, I keep finding out just because I can do something some way, doesn't mean it is right. May 9, 2016 at 13:01
  • @Oxinabox That was my original thought process, but I just wasn't sure if there was more correct or possibly better way to do it. May 9, 2016 at 13:02

2 Answers 2


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.

  • Thank you for this post. I knew hard coding the data in wasn't the best idea at all, and can, quite frankly, just be bad practice. And actually, the JSON and XML serialization was EXACTLY the kind of thing I was looking for (I just had no idea what it was called). May 12, 2016 at 22:43
  • @Gary.Taylor717 Yep, I think this is the middle-ground between hard-coding and using a database. This should also be extensible to databases if you ever decide to make that decision in the future. Add the XML or JSON to your solution, and output it on compile-time to the bin directory along with your executable.
    – Snoop
    May 12, 2016 at 22:44

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.

  • Thanks for the response. While SQL Lite WOULD be an option if this wasn't going to be an application that didn't require being disconnected from an sort of database. And in light of this project, I will need to make changes at some point. All that being said, thank you for the insight, it really has pointed me in some of the right directions. +1 May 12, 2016 at 22:49
  • 1
    Why does it have to be disconnected from a database? Functionally SQL Lite acts like a flat file reader than it does a heavy database.
    – Stephen
    May 12, 2016 at 22:50
  • Because I am too poor to buy and house a server for it to connect to. It's going to be an application that someone installs, builds a team with, and can save it locally, print, modify, and so forth. May 12, 2016 at 22:52
  • @Gary.Taylor717 Don't worry, if you choose JSON you can very simply dump it to MongoDB (which is free) if you ever decide to go that route.
    – Snoop
    May 12, 2016 at 22:55
  • 1
    As StevieV said, there are many free, lightweight database options. Even if they're not applicable to your current project, it would be a good idea to look them up. SQL Lite is the one that I am most familiar with, but MongoDB is quite popular as well. These are lightweight, free to use and won't consume massive resources.
    – Stephen
    May 12, 2016 at 22:57

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.