5

次の相互に排他的な状態のいずれかでなければならないモデルがあります: New、In Progress、またはClosed。

アプリケーションを使用すると、ユーザーはレコードを保存してから、一致する状態のリストを提供することでレコードを取得できます。

状態がビット単位のフラグを表す整数として格納される SQL データベースを継承しました。ビットごとの操作でマッチングを行うプロシージャを呼び出す必要があります。

CREATE PROCEDURE SearchByState
    @MatchingStates       int
AS
BEGIN
    SELECT Id, State
    FROM Records
    WHERE @MatchingStates & State > 0
END;
GO

これは私にとってはすべて問題ありません。

さて、C# の実装では、クエリで一致する状態の組み合わせを表すフラグを定義する必要があることは明らかです。

[Flags]
public enum States
{
    None = 0x0,
    New= 0x1,
    InProgress = 0x2,
    Closed = 0x4,
    All = New | InProgress | Closed
}

問題は、レコードのモデルに単一の状態を表すプロパティが必要なことです。

問題は、このレコードのモデルの State プロパティの型をどうするかです。

1）列挙フラグを使用するだけです：

public class Record
{
    public int Id { get; set; }

    // Must ensure the value is equal to one of
    // States.New, States.InProgress, or States.Closed
    public States State { get; set; }
}

2) 相互に排他的な状態の新しい列挙型を定義します。

public enum State
{
    New,
    InProgress,
    Closed
}

public class Record
{
    public int Id { get; set; }

    // Must be stored as the value of one of 
    // States.New, States.InProgress, or States.Closed
    public State State { get; set; }
}

#1 の欠点はセマンティックです。States 列挙は、単一の状態ではなく、状態の組み合わせを表します。

#2 の欠点は実用的です。状態を格納するとき、格納する基になる値を決定する必要があります。

これらの欠点を最小限に抑えながら、これらすべてを表現する方法を考えられますか?

4

2 に答える 2

4

私はそれを単一の非フラグ列挙型として残します。

これをプロシージャに渡すと、ビット単位または (|) を使用して列挙型から整数を作成したり、単に値を追加したり (int にキャスト) することもできます。単一のレガシークエリを機能させるためにロジックを「壊す」ことを避け、代わりにクエリを呼び出すコードを作り直して、そこでの異常な要件を処理します。

これにより、どこでもコードがきれいに保たれます。あなたの場合の「状態」はフラグ列挙型であってはなりません - 可能な状態は1つだけです。

于 2010-10-12T19:36:15.543 に答える
1

オプション #2 を使用し、Get/Set ステートメントを変更して、基になる値を毎回決定します。このようにして、プロパティを呼び出すたびに実行されます。一度コーディングすれば完了です。

于 2010-10-12T19:35:40.830 に答える