2

私の同僚と私は討論で行き詰まっており、他の人の意見は大歓迎です。

Service Locator パターンと共通インターフェイスを利用してすべてのデータ アクセスを抽象化し、ニーズの変化に応じて異なるデータ ソース間で簡単に交換できるようにします。呼び出しコードには、データがどこにどのように保存されているかは示されていません。サービス レジストリから供給されるサービスを介してデータにアクセスするだけです。

私たちが議論している問題は、オブジェクトに DateTime フィールドがあり、それを MongoDB データソースに保存するときに発生します。

私が気付いたのは、C# に DateTime を持つオブジェクトがある場合、それは正しい時刻として表示されるということです。MongoVUE で MongoDB サーバーにログインしてオブジェクトを調べると、正しい時刻が表示されます。しかし、オブジェクトを取得すると、DateTime は UTC になります。これにより、メモリ内の DateTime を MongoDB データ ソースから取得されたオブジェクト内の DateTime と比較するときに明らかに問題が発生します。

Mongo は DateTime を UTC 時間として内部的に保存することを理解しています。呼び出したときに UTC が返される理由も理解できます。

ここから議論が始まります。

これは単に表面的な問題であり、日付を表示するときの問題であることが示唆されています。したがって、インターフェイス層内で単に .ToLocalTime を呼び出す必要があります。私はこれに同意せず、サービス ロケーター パターンを実装する際に作成した抽象化のレイヤーを危険なほど壊すと断言します。また、他のイベントのトリガーに関連するため、これらの日時との相互作用に関する疑問も生じます。

私が他の場所で読んだことは、時間を文字列として、特にUTC形式の標準として保存する必要があるということです。このように、インターフェイス レイヤーは、DateTime がどのように格納されているかを認識したり気にしたりしません。また、すべてのデータ ソースがその文字列を同じ方法で格納するため、オブジェクトも認識しません。

私は ISO 1806 形式を使用してこれを行うことに成功しましたが、同僚はこれが「ハッキー」な修正であり、.toLocalTime を使用することがこの状況に対処する適切な方法であると感じています。

このトピックについて他の人が何を言おうとしているのかに興味があります。

ご入力いただきありがとうございます。

4

1 に答える 1

8

そもそもUTCをDBに保存しないのはなぜですか?DateTime通常は特定の時点を指すため、ほとんどの場合、 UTC で保存する必要があります。これは、物理的な意味で時間を参照するものすべてに当てはまります。また、時間が単調で、増加し、一意であると仮定するものにも当てはまりますが、ほとんどのローカル時間には当てはまりません。

バスが毎日午前 9 時に出発するとします。これは、連続する 2 つのイベントの間に 24 時間が経過することを意味します。ただし、タイム ゾーンに DST がある場合は、1 年に 1 回、それぞれ 23 時間間隔または 25 時間間隔になります。

ただし、この種のデータを扱う必要がある場合、単純な方法ではうまくいきDateTimeません。DST 規則は変更される可能性があり、タイムゾーンは変更される可能性があります。C# では、適用される DST 規則は、日付が「歴史的」であっても、現在有効なものです。したがって、過去の日付を使用した日付計算は大混乱を引き起こす可能性があります。本当にこれに対処する必要がある場合は、少なくとも、時間がどのタイムゾーンにあるかを保存する必要があります (オフセットだけでなく、isLocalフラグだけでも)。

バイナリに格納できるデータベースにテキスト情報を格納することは、私にはあまりエレガントに思えません。中間層の値を変更することもそうではありません。前者は効率が悪く、前述の現地時間の特性に悩まされますが、後者には 2 つ目の問題しかありません

ところで、後者を達成するには、プロパティを[BsonDateTimeOptions(Kind=DateTimeKind.Local)]で装飾することができます。これにより、変換が行われますが、もちろん同じ問題に悩まされます。

于 2011-12-08T23:09:30.813 に答える