.net - español - ¿Debo hacer un objeto DateRange?

date range picker bootstrap 4

Question

Algunos de mis objetos de dominio contienen intervalos de fechas como un par de propiedades de fecha de inicio y finalización:

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; }
}

Y me encuentro con mucho de esto:

abstract public int Foo(DateTime startDate, DateTime endDate);
abstract public decimal Bar(DateTime startDate, DateTime endDate);
abstract public ICollection<C5.Rec<DateTime, DateTime>> FooBar(DateTime startDate, DateTime endDate);

El último me hizo preguntarme ... ¿Debería implementar una clase DateRange? No conozco ninguno en el BCL.

En mi experiencia, hacer que la jerarquía de objetos sea más profunda a menudo complica las cosas. Estos objetos se envían a informes RDLC mostrados por el control ReportViewer, pero eso es secundario. Doblaré la vista hacia el modelo y no al revés. Sin embargo, no estamos atados a los nombres de las propiedades y estaríamos dispuestos a comprometernos con algo como:

public class DateRange {
  public DateTime StartDate { get; set; }
  public DateTime EndDate { get; set; }
}

Period p = new Period();
DateTime t = p.EffectiveDateRange.StartDate;

Un beneficio de una clase DateRange sería la validación centralizada de la fecha de finalización posterior a la fecha de inicio, y simplificará las firmas de mi método:

abstract public int Foo(DateRange dateRange);
abstract public decimal Bar(DateRange dateRange);
abstract public ICollection<DateRange> FooBar(DateRange dateRange);

Simplemente no estoy seguro de que una clase DateRange no me meta en más problemas de los que merece. Opiniones?

Pregunta complementaria: ¿Eché de menos alguna clase genérica de tuplas de propósito general en el BCL? Sé que hay algunos muy específicos flotando en varios espacios de nombres. La contaminación de mis firmas de métodos de dominio público con tipos C5 parece muy, muy sucia.

Answer 1

Como Mark y Jon ya mencioné, crearía esto como un valor-tipo, que es inmutable. Optaría por implementarlo como una estructura, e implementar las interfaces IEquatable e IComparable.

Al usar un ORM como NHibernate, podrá almacenar el tipo de valor dentro de una tabla que representa una entidad.

Answer 2

En .NET 4.0 o superior, se agregó el tipo Tuple <> para manejar múltiples valores.

Con el tipo de tupla, puede definir su propia combinación de valores sobre la marcha. Su problema es muy común y es similar a cuando una función quiere devolver múltiples valores. Anteriormente, tenía que usar variables o crear una nueva clase solo para la respuesta de la función.

Tuple<DateTime, DateTime> dateRange =
    new Tuple<DateTime, DateTime>(DateTime.Today, DateTime.Now);

Cualquiera que sea la ruta que tome, creo que definitivamente está tomando el enfoque correcto. Estás dando un significado real a las dos fechas juntas. Es código de auto-documentación y de la mejor manera, directamente en la estructura del código.

Answer 3

No conozco ninguna clase .NET nativa de la naturaleza DateRange. El más cercano es probablemente la combinación de DateTime + TimeSpan o DateTime / DateTime.

Creo que lo que quieres es bastante sólido.

Answer 4

No, no te perdiste una clase de propósito general.

Tengo un tipo de Range en MiscUtil que te puede interesar, y ciertamente hace que la manipulación de DateTime sea ​​sencilla. Refiriéndome a la respuesta de Marc, no puedo recordar si se trata de una estructura o una clase; por supuesto, puedes cambiarlo.

Es agradable y fácil de seguir, debido a los chanchullos genéricos de Marc (asumiendo que estés usando .NET 3.5, al menos - es factible con 2.0 pero no es compatible en este momento);

Range<DateTime> range = 19.June(1976).To(DateTime.Today);

foreach (DateTime date in range.Step(1.Days())
{
    // I was alive in this day
}

(Eso también está usando muchos métodos de extensión, más útiles para la prueba que para la producción).

Para abordar el otro punto en la respuesta de Marc, Noda Time ciertamente podrá expresar el concepto de una fecha más apropiadamente que la API de .NET, pero no tenemos nada como un rango en este momento ... Es una buena idea sin embargo, he agregado una solicitud de función .

Answer 5

Si trabajas mucho con las fechas, sí, un rango puede ser útil. Este es realmente uno de esos casos tan raros donde probablemente debería escribirlo como una struct (inmutable). Tenga en cuenta, sin embargo, que "Noda Time" probablemente le proporcione todo esto y más (cuando esté completo). He hecho el software de programación antes; Tenía un par de tales estructuras (para trabajos ligeramente diferentes).

Tenga en cuenta que no hay una construcción BCL útil para esto.

Además, piense en todos los maravillosos métodos (y posiblemente operadores) que puede centralizar cuando tiene un rango; "contiene" (de una fecha y hora? de otro rango? incluyendo / excluyendo límites?), "intersecta", desplazado por (un intervalo de tiempo), etc. Un caso definido para tener un tipo para manejarlo. Tenga en cuenta que en el nivel ORM, esto es más fácil si su ORM admite valores compuestos, creo que NHibernate sí, y posiblemente EF 4.0.