2012-03-08 17 views
2

私は、測定値と測定値の警告/エラー領域を含む大きなデータベースを扱う必要がありました。測定/値の関係の設計パターンはありますか?

public class Measurement<T> 
{ 
    public T Target { get; set; } 

    public float? UpperWarnLimit { get; set; } 
    public float? LowerWarnLimit { get; set; } 
    public float? UpperErrorLimit { get; set; } 
    public float? LowerErrorLimit { get; set; } 
} 

これらの測定値は仕様に割り当てられている:ユーザーが測定を行うたびに

public class Specification 
{ 
    public long Id { get; set; } 
    public Measurement<float> Width { get; set; } 
    public Measurement<float> Height { get; set; } 
    public Measurement<int> AdditionalMeasurement { get; set; } 
    // ... 
} 

そこで、システムは、様々なデータベースのテーブルから情報を収集仕様オブジェクトをアセンブルし、測定値を収集します。いくつかのケースでは仕様が変更する必要があります。

public interface IDatabase 
{ 
    Specification GetSpecification(long id); 
    void UpdateSpecification(Specification specification) 
} 

すべてがこれまでのところ良いように見えますが、ユーザーがデータベースにテスト結果を保存するために持って、私が何であるかわからない場合もありますこの問題を解決する最善の方法。

public class Measurement<T> 
{ 
    public T Target { get; set; } 
    public T Value { get; set; } // <-- New 


public interface IDatabase 
{ 
    void StoreTestResults(Specification specification) // <-- New 

しかし、実際には、ユーザがテスト結果ではなく仕様を格納するため、それは、右感じていない:

私の最初のソリューションは、このような測定およびデータベース・クラスを変更することでした。私はこれを行うより良い方法を探しています。

これをクリアするにはできるだけ複雑な複雑さを最小限に抑えてテスト結果を仕様から分離したいと考えています。

Iが挙げ変化を有する典型的なコードシナリオ:

var s = GetSpecification(123); 
s.Height.Value = 4; 
if (s.Height.Value > s.Height.Target * s.Height.Target.UpperErrorLimit) 
{ 
    ... 
} 
StoreTestResults(s); 

これは簡単であり、かなりまっすぐ進むが、テスト結果と仕様自体との間に明確な分離が存在しません。

+1

この点をもう少し説明したら、おそらくあなたがしていることの具体的な例を挙げておけば助かります。 – Marcin

+0

@Marcin:コードサンプルを追加しました。 – xsl

答えて

1

あなたのデザインには問題はありませんが(詳細はほとんどありませんが)、

「仕様」という名前を使用すると、仕様を格納することに惑わされている可能性があります。

タイプレベルで結果から仕様を分離する必要がある場合(および必要がない場合はそうしないことを強くお勧めします)、すべての共通要素(すべてである可能性があります)を含む基本クラスを作成し、それは仕様と結果であり、ニュートラルな名前を使用します。

では、2つの概念を分離する必要がない場合は、「仕様」よりも中立な名前を選択してください。

+1

あなたの答えをありがとう。私はまだそれを受け入れていない、私は明らかに異なる意見やアイデアに興味があるので。 – xsl

+0

@xsl私はいつも待っています。 – Marcin

0

Measurement<T>クラスをオーバーロードしていると思います。あなたはあなたの限界とテスト結果の両方をカプセル化するためにそれを使用しています。これを2つの別々のクラスに分割することもできます。これはどうやって聞こえる?

これにより、テストデータから仕様データを分離することができ、テストの複数のインスタンスが同じ仕様を参照することができます。

+0

ありがとうございます。私もここで説明したのと同様の解決策を考えましたが、問題はテスト結果クラスですべての仕様プロパティを繰り返す必要があることです。これを避ける方法はありますか? – xsl

+0

あなたはきれいな分離をしたい場合はありません。ハードコーディングされたプロパティを持たないと思う唯一の方法です。その代わりに、キーがプロパティの名前を含む文字列であるHashTable/Dictionaryを実装し、オブジェクトは仕様のAcceptableRangeとなり、TestResultのMeasurementとなります。これはここでコードを簡素化しますが、コードを他の場所に配置してコレクションに追加する必要があります。 –

+0

これは多くの複雑さをもたらします。どのようなメリットがありますか? – Marcin

関連する問題