How would you structure a model for this RavenDB document?

Question

I've got the following structure for a RavenDB document

{
    "RpcTechDataCollectionModel": {
        "Weekend": "March 16 - 17, 2013",
        "ServiceTitle": "Some Title",
        "Notes": "",
        "WeekendServices": [{
            "ServiceTime": "",
            "SiteName": "Bowridge",
            "SoundOperator": "Rob",
            "WorshipLeader": "Daryl",
            "Notes": "",
            "Songs": [{
                "SongName": "Foo",
                "MinSpl": "86",
                "MaxSpl": "92",
                "Note": ""
            }, {
                "SongName": "Bar",
                "MinSpl": "89",
                "MaxSpl": "96",
                "Note": ""
            }]
        }, {
            "ServiceTime": "",
            "SiteName": "Bearspaw",
            "SoundOperator": "Peter",
            "WorshipLeader": "Tim",
            "Notes": "",
            "Songs": [{
                "SongName": "Das",
                "MinSpl": "86",
                "MaxSpl": "91",
                "Note": ""
            }, {
                "SongName": "Bar",
                "MinSpl": "87",
                "MaxSpl": "99",
                "Note": ""
            }]
        }]
    }
}

Now I'm trying to build a model for this, but I'm wondering what the best way to structure it would be. Note, none of the sub-objects WeekendService or Song will be used outside of the parent object RpcTechCollectionModel

option one would be

namespace MyProject.Models {
    using System.Collections.Generic;
    public class RpcTechDataCollectionModel{
        RpcTechDataCollectionModel(){
            this.WeekendServices = new List<WeekendService>();
        }
        public string Weekend { get; set; }
        public string ServiceTitle { get; set; }
        public string Notes { get; set; }
        public List<WeekendService> WeekendServices { get; set; }
        public class WeekendService{
            WeekendService(){
                this.SongRecords = new List<SongRecord>();
            }
            public DateTime ServiceTime { get; set; }
            public string SiteName { get; set; }
            public string SoundOperator { get; set; }
            public string WorshipLeader { get; set; }
            public string Notes { get; set; }
            public List<Song> Songs { get; set; }
            public class Song {
                public string SongName { get; set; }
                public double MinSpl { get; set; }
                public double MaxMax { get; set; }
                public string Note { get; set; }
            }
        }
    }
}

I prefer this as it is nice and clean, and easy to understand. The problem is that it technically violates the "One class per file" rule

option two

public class RpcTechDataCollectionModel{
    RpcTechDataCollectionModel(){
        this.WeekendServices = new List<WeekendService>();
    }
    public string Weekend { get; set; }
    public string ServiceTitle { get; set; }
    public string Notes { get; set; }
    public List<WeekendService> WeekendServices { get; set; }
}

public class WeekendService{
        WeekendService(){
            this.SongRecords = new List<SongRecord>();
        }
        public DateTime ServiceTime { get; set; }
        public string SiteName { get; set; }
        public string SoundOperator { get; set; }
        public string WorshipLeader { get; set; }
        public string Notes { get; set; }
        public List<Song> Songs { get; set; }

}

public class Song {
    public string SongName { get; set; }
    public double MinSpl { get; set; }
    public double MaxMax { get; set; }
    public string Note { get; set; }
}

This does not violate that rule, but seems like a bit of a pain.

What would be the pros/cons to doing it one way or the other, and is one way considered "right / prefered", or is it more "whatever floats your boat" in a situation like this?

score 2 · Accepted Answer · answered Mar 17 '13 at 04:42

2

Nested classes are usually used to hide implementation details, and thus prevent consumers from misusing them. As these classes just define data contracts, there seems to be nothing to hide. Even if you wanted to prevent anyone from modifying them (which makes sense for data contracts you keep ownership of), better make them sealed.

I would have them in different files and perhaps grouped in folder.

answered Mar 17 '13 at 04:42

driushkin

3,531
1
24
25

This makes good sense. I suppose decoupling it all adds flexibility in the event that we need info separate from the current implementation. – Chase Florell Mar 18 '13 at 20:37

How would you structure a model for this RavenDB document?

1 Answers1