2012-03-06 5 views
2

私は動的にロードされるタイプを持っています。可変部分はdbのxmlフィールドから読み込まれます。例えば。動的にロードされるタイプの後方互換性を保証する

<element> 
    <name>Name</name> 
    <type>string</type> 
</element> 
<element> 
    <name>Url</name> 
< type>string</type> 
</element> 
<element> 
    <name>FallbackUrl</name> 
    <type>string</type> 
</element> 
から

class SomeClass 
{ 
    public int Id {get; set;} 
    public string Name {get; set;} 
    public string Url {get; set;} 
    public string FallbackUrl {get; set;} 
} 

class SomeClass 
{ 
    public int Id {get; set;} 
    public string Name {get; set;} 
    public string Url {get; set;} 
} 

名とURLの部分がその後クラスの

<element> 
    <name>Name</name> 
    <type>string</type> 
</element> 
<element> 
    <name>Url</name> 
    <type>string</type> 
</element> 

のXMLセクションを読むことによってcontructedされているが、動的にロードされます

どのように後方互換性がありますか意味を維持していますか?クラスの後半で拡張すると、新しいバージョンが古いバージョンのdbs(いつかそうであるかもしれません)にデプロイされたときにクラッシュすることはありませんか?特に http://www.xfront.com/Versioning.pdf

(抽象):

+2

あなたはあなたが心配しているシナリオについてより明確になりますか?私は、DTOなどのバージョン管理にかなり精通していますが、あなたの意図は明確ではありません。 –

+0

これは、後方互換性を保証するためです。つまり、拡張型を含むバージョンが古いDBにデプロイされている場合、クラッシュせず、より小さいサブセットまたはプロパティでのみ正常に機能します。 – Elena

+0

Xmlをデシリアライズしていますか?あるいは単にXMLを読んで値を割り当てるのですか?最良の結果とコントロールを得るには、MSDNでIXmlSerializableをチェックしてください。 – IAbstract

答えて

3

は、読み取りをお持ちの

は、XMLスキーマへの変更のための2つのケースを考えてみましょう:新しいスキーマ1.

ケースは、いくつかの解釈を変更します素子。たとえば、以前のスキーマで有効で意味のある構文は、新しいスキーマに対して検証されません。

ケース2.新しいスキーマは、(例えば、新しい要素を追加することによって)名前空間を拡張するが、それ以前に有効な文書を無効にしない。

  1. 変更(内部)スキーマのバージョン属性:

    新しいスキーマバージョンを識別するためのいくつかのオプションがします。

  2. ルート要素にschemaVersion属性を作成します。
  3. スキーマのtargetNamespaceを変更します。
  4. スキーマの名前/場所を変更します。

XMLスキーマのバージョン管理のベストプラクティス

[1] XMLスキーマのどこかにスキーマのバージョンをキャプチャします。

[2]インスタンス文書で、インスタンスが互換性のあるバージョン/バージョンのスキーマを特定します。

[3] XMLスキーマの以前のバージョンを使用可能にします。

[4] XMLスキーマのみが拡張された場合、(例えば、新しい要素、属性、列挙されたリストの拡張機能、など)1は、既存のインスタンス文書

を無効にしないように努力すべきである

[5]ここで、新しいスキーマはいくつかの要素の解釈を変更します(例えば、 の構文は有効であり、以前のスキーマでは意味がありません。 新しいスキーマに対して検証されません)、ターゲット名前空間を変更する必要があります。

関連する問題