1

ここに問題があります：私たちのメインクラス（たとえば：契約）は毎年変わります。一部のプロパティが追加され、その他は削除されます。来年はどうなるかわかりません。大きく変わることもあれば、まったく変わらないこともあります。

一方、(新しい要件...) すべての契約の履歴を保持する必要があります。ユーザーがコントラクトを更新するたびに、オブジェクト全体をバックアップに保存する必要があります (例: テーブルにシリアル化)。

もちろん、それを読み返すことができる必要があります... 1 つのオプション (残忍) は、毎年新しい契約クラス (Contract2008、Contract2009、...) を持つことです。

しかし、多くのクラスが Contract に依存しているため、これは非常に面倒 (かつ醜い) です。実際には、毎年新しいクラスを多数作成する必要があります。

この種の問題はありますか？なにか提案を ？

前もって感謝します ！

(C# 2.0 を使用しています。)

追加: ご回答ありがとうございます。私たちは現在、辞書や XML ファイルを使用して、すべてのコードを壊さずにバージョン管理を実装する方法を自問しています。このコンテキストでは、辞書は非常にセクシーに見えます:o)

4

3 に答える 3

4

オブジェクトのシリアル化を停止します。データをリレーショナルに格納します。シリアライゼーションは、ネットワークを介したストリーミングのように、短期間を対象としています。永久保存ではありません。

フィールドをクラスにコーディングする代わりに。年ごとに保存されたデータベース構成値に基づいてフィールドを動的に取得できる、辞書のような構造がさらに必要になるようです。次に、それらの値に基づいて動的 UI を構築します。毎年新しいクラスを作成してコードをテストしなければならないのは、維持するのに非常にコストがかかるようです。

于 2009-01-16T05:31:17.060 に答える
2

最初に頭から離れて考えることができること。一種の「機能」ドキュメントを実装します。連絡先のバージョンとそれに含まれるプロパティの詳細を示すリスト (または XML ドキュメント)。

Contract で動作する各関数は、特定のプロパティ (「機能」) がサポートされているかどうかを確認する必要があります。

例えば：

Contract2008 Capabilities
-----
has Name
has Stipulations
can DoMagic
-----
>     
>     Contract2009 Capabilities
>     -----
>     has Name
>     has Stipulations
>     can DoMagic
>     -----

コントラクト クラスは、ケーパビリティ ドキュメントといくつかの一般的なゲッター セッターを格納します。

Contract
  GetCapabilities()
  Set(field, value)  
  Get(field, value)

set と get は、値を設定または取得する前に、フィールドが機能でサポートされているかどうかを確認します。

（これはパターンか何かに違いない、誰か？）

于 2009-01-16T05:19:36.867 に答える
2

ほとんどの場合、プロパティを C# プロパティとして実装する必要はありません。実際に何らかの辞書にプロパティを格納し、Get および Set メソッドを使用してそれらを読み取り/列挙することができます。その場合、毎年同じクラスをご利用いただけます。

プロパティが本当にプロパティである必要がある場合は、毎年クラスを使用して新しいアセンブリを構築し、アセンブリを動的にロードすることをお勧めします。その後、リフレクションを使用して、各 Contract オブジェクトでサポートされているプロパティを確認できます。作業を楽にするために、変更されないプロパティのインターフェイスを用意し、アセンブリ内の Contract クラスを簡単に識別できるようにすることをお勧めします。

于 2009-01-16T05:31:00.993 に答える