2

TimeSheetActivityクラスには、Allocationsのコレクションがあります。割り当ては、ドメイン内の他のオブジェクトによっても使用される値オブジェクトであり、次のようになります。

public class Allocation : ValueObject
{
    public virtual StaffMember StaffMember { get; private set; }
    public virtual TimeSheetActivity Activity { get; private set; }
    public virtual DateTime EventDate { get ... }
    public virtual TimeQuantity TimeSpent { get ... }
}

同じAllocation.EventDateに重複して割り当てることはできません。したがって、クライアントがアクティビティに割り当てを行おうとすると、同じAllocation.EventDateのコレクションにすでにAllocationがあるかどうかがチェックされます。そうでない場合は、新しい割り当てがコレクションに追加されますが、追加されている場合は、既存の割り当てが新しい割り当てに置き換えられます。

私は現在、Allocation.EventDateをキーとして、コレクションを維持するためにディクショナリを使用しています。ドメインでは問題なく動作しますが、キーがすでに値の一部になっているという事実自体が「悪臭」ではないかと思います。

また、辞書の値以外のものを永続化する理由はありません。私はNHibernateを使用しているので、それを行うためにカスタムタイプを作成する必要があるかもしれません。それが、別のタイプのコレクションを使用する必要があるという手がかりにもなるのではないかと思います。（これが、Allocationクラスの仮想プロパティの理由でもあります）。

私が考えている主な代替案は、専用のEqualityComparerを備えたHashSetです。

どう思いますか？

乾杯、ベリール

4

3 に答える 3

3

キーが値の一部であるという事実は必ずしも問題ではないと思います。私の経験では、それは辞書の場合によくあることです。HashSet特定ので現在のオブジェクトに到達する必要がない限り、適切な等式比較器を備えたAは確かに機能しますEventDate。それができると便利なことのように思えます、潜在的に...

あなたは現在、やや漠然とした方法で心配していますか、それともこれがあなたをどのように噛むかについて具体的な疑いがありますか？

于 2009-06-27T22:00:02.340 に答える
3

外部比較機能を使用してを実行するHashSet<Allocation>場合は、ディクショナリの値を再入力せずに日付を変更しないように十分に注意する必要があります。どちらの方法でもこの問題が発生しますが、可変性によって悪化します（少なくとも、Dictionary<,>それ自体のキーと値を追跡することはできます）。キーの一部として可変値を使用すると、値が二度と表示されないリスクがあります...

過去にスケジュールシステムに取り組んだとき、私は実際にこれを使用SortedList<,>しました-同様ですが、一般的にデータを順番に並べたい場合に役立ち、データがかなり均一である場合はバイナリ検索が可能です。

于 2009-06-27T22:01:04.833 に答える
2

標準ライブラリを使用すると、私が知っているより良い解決策はありません。ただし、この種のコードも「悪臭」だと感じましたが、これはBCLのコレクションクラスが原因であり、コードが原因ではありません。

<TKey, TData> where TData: IKeyed<TKey>キーがデータの一部であるようなデータ構造を実装できるため、MSが辞書の代わりに汎用セットなどを作成しなかった理由はわかりません。これKeyValuePair<TKey, TValue>: IKeyed<TKey>は、このインターフェイスを実装するヘルパー構造であり、現在と同じ辞書機能を作成できます。

また（小さな暴言を続けるために）なぜ彼らは宣言型の不変型の概念を追加せず、これを可能なジェネリック型制約にしたのだろうか？これにより、実行時にキーがハッシュコードを変更しないようにすることができます（これにより、現在、いくつかの可変オブジェクトを実装GetHashCode()した場合に発生します）。Equals()

于 2009-06-27T23:16:19.160 に答える