2

開発環境は、SQL Server 2008 データベースと Entity Framework を備えた C# 3.5 です。

ソフトウェアが制御する必要があるサードパーティによって作成された物理的な電子サインを表す Sign という名前のクラスとテーブルがあるとします。標識との実際の通信を処理する SignDriver というクラスもあります。サインのプロパティ/列は、サイン ドライバーがサインと適切に対話するために必要な構成可能な情報を表します。

すべてが素晴らしく、あなたは背中を徹底的に叩きました。次に、別のサインと話す必要が生じます。ただし、この記号は前のものとは動作が異なり、Sign クラスとテーブルに追加情報を格納する必要があります。5 つの新しいもの (列/プロパティ) を保存する必要があるとしますが、残念ながら、最初のタイプの標識はこれら 5 つのものを必要としません。次に、各タイプの記号を 10 個制御したい場合、テーブルに多くの NULL 値があることがわかります。

ドメイン モデルは、Sign のようなクラスが増えるまで成長します。各クラスは、問題ドメインの異なる部分を表し、それぞれがデータベース内の対応するテーブルを持ちます。各クラスは、そのタイプの共通情報を適切に収集するという同じ問題を抱えていますが、各タイプの特殊化にはまったく対応していません。

問題の性質上、制御すべき兆候の種類が増え、対応すべき他のエンティティの種類が増えることを意味します。より拡張可能なモデルが必要です。

このようなシステムの最善の方法は何でしょうか??

私はこれについて同僚と長々と話し合いましたが、このような問題に取り組む最善の方法は何かを知りたいと思っています. 特に、多くの人が過去に直面したであろう問題のように思えるからです。

以下は、私たちが思いついたオプションと、それぞれについてのいくつかのポイントです。

  • 1 対 1 の関係を共有するエンティティごとに n個の「タイプ」クラスとテーブルを作成します。
    • 非常に継承的です。
    • 伸ばすときに一番時間がかかります。
    • 多くのテーブル。
  • キーと値のペアを保持するために、エンティティごとに 1 つの「拡張プロパティ」テーブルを作成します。
    • 参照整合性。
    • 拡張可能。
  • Create one global ‘extended properties’ table to store properties for ANY entity. (schema: entityType, entityId, key, value, dataType)
    • Super extensible.
    • Cannot have referential integrity with existing tables.
    • Doesn’t look like Entity Framework will be able to handle this well.

What would you do and why??

Any help greatly appreciated. Cheers.

4

1 に答える 1

2

この質問は、ソフトウェア設計の複数の問題に触れています。

あなたの主な問題は、継承階層をデータベーステーブルにマッピングすることにあるようです。これは広範囲に分析されています。Martin Fowler の著書「Patterns of Enterprise Architecture」を参照してください。ここで簡単な概要を確認できますが、本の方が優れており、すべての OO 開発者の棚にあるはずです。「サブクラスごとのテーブル」パターンと「クラス階層ごとのテーブル」パターンを比較します。

いくつかの一般的なアドバイス: 継承が多すぎることに注意してください - 継承よりも構成を優先してください。ほとんどの場合、継承を回避するためにリファクタリングできます。基本的に、Sign クラスから切り離された「特殊化」で終わります。これにより、テーブル階層を作成するという点で前進することができます。前述のように、Head First Design Patternsブックは開始するのに適した場所です。

また、たくさんのクラスとたくさんのテーブルを持つことを恐れないでください。一般に、柔軟な設計では多くのクラスとテーブルが好まれます (もちろん、これを行うことには欠点もありますが、最善の妥協点を決定するのはあなた次第です)。

于 2010-02-12T07:42:40.227 に答える