DateRange 객체를 만들어야합니까?

DateRange 객체를 만들어야합니까?

---

내 도메인 개체 중 일부에는 시작 및 종료 날짜 속성 쌍으로 날짜 범위가 포함되어 있습니다.

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

그리고 나는 이것의 많은 것을 발견합니다 :

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

마지막 질문은 나를 궁금하게 만들었습니다. DateRange 클래스를 구현해야합니까? 나는 BCL에서 하나를 알지 못합니다.

내 경험상 객체 계층 구조를 더 깊게 만드는 것은 종종 일을 복잡하게 만듭니다. 이러한 개체는 ReportViewer 컨트롤에 의해 표시되는 RDLC 보고서로 전송되지만 이는 보조입니다. 그 반대가 아닌 모델로 뷰를 구부릴 것입니다. 그러나 우리는 속성 이름에 묶여 있지 않으며 다음과 같이 기꺼이 타협 할 것입니다.

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

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

DateRange 클래스의 이점은 시작 날짜 이후의 종료 날짜에 대한 중앙 집중식 유효성 검사이며 내 메서드 서명을 단순화합니다.

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

나는 DateRange 클래스가 그 가치보다 더 많은 문제를 일으키지 않을 것이라고 확신하지 않습니다. 의견?

부차적 인 질문 : 어딘가에 BCL에서 일반적인 범용 튜플 클래스를 놓쳤습니까? 다양한 네임 스페이스에 매우 특정한 것들이 떠 다니는 것을 알고 있습니다. 퍼블릭 도메인 메서드 서명을 C5 유형으로 오염시키는 것은 매우 더럽게 느껴집니다.

---

아니, 당신은 범용 수업을 놓친 것이 아닙니다.

나는 당신이 관심을 가질만한 MiscUtil에Range 타입을 가지고 있으며 그것은 확실히 간단한 조작 을 가능하게 합니다. Marc의 답변을 참조하면 이것이 구조 체인지 클래스인지 기억할 수 없습니다. 물론 변경할 수 있습니다.DateTime

Marc의 제네릭 헛소리 (최소한 .NET 3.5를 사용한다고 가정하면 2.0에서는 실행 가능하지만 현재 지원되지는 않음)로 인해 단계별로 쉽게 진행할 수 있습니다.

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

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

(그것은 또한 많은 확장 방법을 사용하고 있습니다-프로덕션보다 테스트에 더 유용합니다.)

Marc의 대답의 다른 점을 다루기 위해 Noda Time 은 확실히 .NET API보다 날짜 개념을 더 적절하게 표현할 수 있지만 현재로서는 범위와 같은 것이 없습니다 ... 좋은 생각입니다. 그래도- 기능 요청을 추가했습니다 .

---

.NET 4.0 이상에서는 여러 값을 처리하기 위해 Tuple <> 유형이 추가되었습니다.

튜플 유형을 사용하면 즉시 값 조합을 정의 할 수 있습니다. 문제는 매우 일반적이며 함수가 여러 값을 반환하려는 경우와 유사합니다. 이전에는 변수를 사용하거나 함수의 응답만을위한 새 클래스를 만들어야했습니다.

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

어떤 경로를 택하든 확실히 올바른 접근 방식을 취하고 있다고 생각합니다. 당신은 함께 쌍을 이루는 두 날짜가 무엇인지에 대한 진정한 의미를 부여하고 있습니다. 이것이 바로 코드 구조에서 자체 문서화 코드이며 가장 좋은 방법입니다.

---

If you do a lot of work with dates, yes - a range can be handy. This is actually one of those oh-so-rare cases where you should probably write it as a struct (immutable). Note, however, that "Noda Time" will probably give you all of this and more (when it is complete). I've done scheduling software before; I had a couple of such structs (for slightly different jobs).

Note, there isn't a handy BCL construct for this.

Also - think of all the wonderful methods (and possibly operators) that you can centralise when you have a range; "contains" (of a datetime? of another range? including/excluding limits?), "intersects", offset-by (a timespan), etc. A definite case for having a type to handle it. Note that at the ORM level, this is easier if your ORM supports composite values - I believe NHibernate does, and possibly EF 4.0.

---

I do not know of any native .NET class of the DateRange nature. The closest is probably DateTime+TimeSpan or DateTime/DateTime combination.

I think what you want is fairly sound.

---

As Mark and Jon already mentionned, I would create this as a value-type, which is immutable. I would opt to implement it as a struct, and implement the IEquatable and IComparable interfaces.

When using an ORM like NHibernate, you will be able to store the value type inside a table which represents an entity.

참고URL : https://stackoverflow.com/questions/1845493/should-i-make-a-daterange-object