title: Should I make a DateRange object?
body: <p>A few of my domain objects contain date ranges as a pair of start and end date properties:</p>
  
  <pre><code>public class Period {
    public DateTime EffectiveDate { get; set; }
    public DateTime ThroughDate { get; set; }
  }
  
  public class Timeline {
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
  }
  </code></pre>
  
  <p>And I find myself with a lot of this:</p>
  
  <pre><code>abstract public int Foo(DateTime startDate, DateTime endDate);
  abstract public decimal Bar(DateTime startDate, DateTime endDate);
  abstract public ICollection&lt;C5.Rec&lt;DateTime, DateTime&gt;&gt; FooBar(DateTime startDate, DateTime endDate);
  </code></pre>
  
  <p>The last one made me wonder ... Should I implement a DateRange class?  I'm not aware of one in the BCL.</p>
  
  <p>In my experience, making the object hierarchy deeper often complicates things.  These objects do get sent to RDLC reports displayed by the ReportViewer control, but that's secondary.  I'll bend the view to the model rather than vice versa.  We aren't tied to the property names, though, and would be willing to compromise with something like:</p>
  
  <pre><code>public class DateRange {
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
  }
  
  Period p = new Period();
  DateTime t = p.EffectiveDateRange.StartDate;
  </code></pre>
  
  <p>A benefit of a DateRange class would be centralized validation of the end date coming after the start date, and it will simplify my method signatures:</p>
  
  <pre><code>abstract public int Foo(DateRange dateRange);
  abstract public decimal Bar(DateRange dateRange);
  abstract public ICollection&lt;DateRange&gt; FooBar(DateRange dateRange);
  </code></pre>
  
  <p>I'm just not sure that a DateRange class won't get me into more trouble than its worth.  Opinions?</p>
  
  <p>Side question:  Did I miss a generic general-purpose tuple class in the BCL somewhere?  I know there's some very specific ones floating around in various namespaces.  Polluting my public domain method signatures with C5 types feels very, very dirty.</p>