0

On my website, I have a score sheet that the user fills out. They will USUALLY have 10 items on a score sheet and each item will have its own score. I am wanting to design this in the best way for future expandability. What If I want to have more or less items on the score sheet in the future?

Here is what I have now:

public class Scoresheet712Item
    {
        public int ScoresheetItemId { get; set; }
        public int ScoresheetId { get; set; }
        public int DistanceAway { get; set; }
        public int score { get; set; }
    }

Is it better to do this or is it better to have all 10 scores and distances on the same row? I would rather have them in the same row because I can pull that one row directly in as a model. I originally thought to do it this way so I could easily vary how many slots there are on the score sheet, but it doesn't seem like there is much benefit really, specifically because I am using MVC development and I will always need the entire score sheet.

Please help, can I have all the data in one row for a score sheet and that be good practice?

Here is what I am trying to propose, it would be a little different though because each score DOES have a different purpose.:

public class Scoresheet
        {
            public int ScoresheetId { get; set; }
            public int DistanceAway1 { get; set; }
            public int score1 { get; set; }
            public int DistanceAway2 { get; set; }
            public int score2 { get; set; }
            public int DistanceAway3 { get; set; }
            public int score3 { get; set; }
            public int DistanceAway4 { get; set; }
            public int score4 { get; set; }
            public int DistanceAway5 { get; set; }
            public int score5 { get; set; }
            public int DistanceAway6 { get; set; }
            public int score6 { get; set; }
            public int DistanceAway7 { get; set; }
            public int score7 { get; set; }
            public int DistanceAway8 { get; set; }
            public int score8 { get; set; }
            public int DistanceAway9 { get; set; }
            public int score9 { get; set; }
            public int DistanceAway10 { get; set; }
            public int score10 { get; set; }
        }

Like this?

public class Scoresheet712
    {
        public int Scoresheet712ID { get; set; }
        public virtual ICollection<Scoresheet712Item> Scoresheet712Items { get; set; }
    }
  • Your class should have a collection property for the scores (a class containing properties `int DistanceAway` and `score`) so that you can have as many as you want. –  Nov 01 '16 at 12:25
  • like that? (I added it to the bottom of my question) –  Nov 01 '16 at 12:37
  • Yes, something like that (where `Scoresheet712Item` contains properties `DistanceAway` and `score`) –  Nov 01 '16 at 12:47

1 Answers1

0

I am inclined to agree with @Stephen Muecke to be flexible and extendable you really need two sql tables.

public class Scoresheet
{
    public int ScoresheetId { get; set; }
    public string ScoresheetName { get; set; }
    public ICollection<ScoresheetItem> ScoresheetItems { get; set; }
}

And

Public class ScoresheetItem
{
    public int ScoresheetItemId { get; set; }
    public int Score { get; set; }
    public int Distance { get; set; }
    //Navigation properties
    public int ScoresheetId { get; set; }
    public Scoresheet Scoresheet { get; set; }
{

This will let you build a new Scoresheet as needed with as many or as few items as you want. The example below shows the usage.

//Create a new Scoresheet
Scoresheet scoresheet712 = new Scoresheet()
{
    ScoresheetName = "Score Sheet 712",
    ScoresheetItems = new List<ScoresheetItem>()
};
//Add a ScoresheeItem to Scoresheet
scoresheet712.ScoresheetItems.Add(new ScoreSheetItem()
{
    Score = 10,
    Distance = 150
});

Remember that on your View you do not need to use your Data Model you can always add a Data Transfer Object (Scoresheet_DTO) and make the flat structure for your score sheet if it really does make displaying it easier/better, just be sure to use nullable integers.

UPDATE MANY-TO-MANY RELATIONSHIP

For a many-to-many relationship if setup correctly in code it will automatically create the joining table. The Scoresheet class would remain the same but the ScoresheetItem class would have a small change to the Relationship/Navigation properties.

Public class ScoresheetItem
{
    public int ScoresheetItemId { get; set; }
    public int Score { get; set; }
    public int Distance { get; set; }
    //Navigation properties
    public ICollection<Scoresheet> Scoresheet { get; set; }
{

For further help I would recommend taking a look at this Entity Framework Tutorial

Jared Stroebele
  • 574
  • 6
  • 25
  • A question on this. Will this create the third table automatically or is there something else that I will have to do to make this work? Also, this represents many to one correct? How far is this from many to many? I am trying to implement both concepts. –  Nov 04 '16 at 11:26
  • My original answer demonstrated a one-to-many relationship. That relationship does not require a third table. I updated my code to show a many-to-many. This relationship does require a third table referred to as a joining table it will contain only the two foreign keys and will be automagically created by Entity Framework. – Jared Stroebele Nov 04 '16 at 13:56
  • Thanks! I appreciate it.I am really struggling with this implementation still. –  Nov 04 '16 at 17:28
  • 1
    Another question about the one-to-many. I see the usage and understand it, but I am working on handing that data from my view to the controller. Basically in my system, I have a "+" sign that adds two boxes, one for score and one for distance. It is unclear to me how to get that list from the view without knowing exactly which ones are there and how long the list is? Also, On the entity framework tutorial that you listed, it has a section on "configuring" the one to many relationship. In your answer you didn't include it, is it necessary? –  Nov 08 '16 at 19:11
  • Also, I see some people not using virtual and ICollection. I see some people using public List. What is the differrence? –  Nov 08 '16 at 19:23
  • The MVC question is too complicated to handle in the comments here, try asking another question on StackOverflow. In the tutorial "Configuring" is just referring to setting the classes up correctly OR using Fluent API to create the Many-to-Many relationship. The classes in my answer should be all you need for this example. – Jared Stroebele Nov 08 '16 at 20:03
  • Virtual is used with lazy loading. Many enterprise level projects disable lazy loading preferring a finer control over when relational objects are loaded. The tutorial in my answer has a section for lazy, explicit, and eager loading. A List Implements ICollection. A List will generally provide all the functionality needed, ICollection provides more flexibility just in case. There are SO questions that deal with solely that choice [ICollection or List](http://stackoverflow.com/questions/10113244/why-use-icollection-and-not-ienumerable-or-listt-on-many-many-one-many-relatio) – Jared Stroebele Nov 08 '16 at 20:20