質問

Microsoft SQL Server 2005のXMLデータ型をプロジェクトに使用しています。チームの一部のメンバーと私は、XSDも使用する必要があると感じていますが、他のキャンプのメンバーは、XMLをアドホックに保ち、「タイプ」として扱わないようにする必要があると感じています。

XMLは、メンテナンスの悪夢である多くのテキスト構成ファイルに構造と中心性をもたらすための取り組みです。

.NET 3.5 / C#を使用しており、テーブルは適切なデータ型で設計されています。 私の主張は、すでに「型指向」であるということです。それがXMLであるために、なぜこのアプローチを破るのかという考えで。元の問題が発生したのは、テキストファイルに型がないためです。 「タイプ」を使用しないアプローチでは、同じ問題を受け入れることができます。

XMLスキーマの利点についての私の理解が間違っているかもしれません。 では、XMLスキーマを使用する利点と欠点は何ですか?

役に立ちましたか?

解決

残念ながら、XSDのオーサリング機関(W3C)でさえ、XSDがかなり悪い技術であることを理解しています。とはいえ、意図は必ずしも悪いわけではありません。 C#の主な利点の1つは、静的に型指定されることです。 XMLドキュメントを静的に入力すると、同じ利点が得られます。ここでおそらく最良の方法は、クラスをリバースエンジニアリングして、XMLシリアル化属性を使用してスキーマを生成することです。これを行うと、C#はXMLファイル用のカスタムデータリーダーを作成し、パフォーマンスを劇的に改善します。

XMLの最大のコストの1つは、文字列を解析する必要があることです。 XMLファイル(たとえば、その構造)についてより多くの仮定を立てることができるほど、パフォーマンスが向上する可能性が高くなります。

最終的に多くのことと同様に、開発者の時間のコストを正当化するために、パフォーマンス上の利点が十分に必要です。または、静的に型指定されたシステムを使用して、XSDの記述コストを正当化する強い要望があります。

最終的にはプロジェクトのニーズによって何をすべきかが決まりますが、静的な型付けとパフォーマンスは考慮すべき大きな利点です。

他のヒント

XSDを使用せずにXMLのリポジトリを保持することは、すべての型がVARCHAR(n)として宣言されているデータベースを持つことに似ています(私の意見では)。どんな種類の入力を受け取るかは気にせず、ただ入力したいだけです。

XSDは、XMLが期待するタイプの入力であることを保証します。彼らはあなたのモデル、まさにあなたが探しているものに構造を与えます。

さて、他の投稿や質問で述べたように、XSDはXMLの適切な場所で適切な型を使用していることを保証し、その構造を変更する前によく考えなければなりません。

しかし、私がそう言うことができるならば、XSDは本当に過度に冗長です。また、条件付きコンテンツを含む複雑な構造を記述するのは、実際には非常に複雑です。

うまくいけば、XSDがXMLを検証する唯一の方法ではなく、もっと簡単なアプローチは RelaxNG を使用することです、特にXSDで想像できるよりも読みやすいコンパクトな構文です。

スキーマを使用することの大きな利点の1つは、XMLドキュメントのレイアウト方法についてプロジェクトの全員が同意することを確認できることです。また、スキーマを使用することにより、XMLパーサーで検証を有効にでき、不適切なXMLが与えられたためにコードの一部が失敗したことを簡単に識別できます。

マイナス面として、スキーマを維持するのは苦痛であり、プロジェクトによっては努力する価値がないかもしれません。

スキーマがない場合、すべての検証を自分で再実装することになります(または、検証をまったく行わず、無効な入力でクラッシュします)。 XSDパーサー/バリデーターはすべての作業を行い、ドメインの専門家によって最適化およびデバッグされます。なぜあなたはそれらすべてを自分でやり直すのですか?

XSDは、利用可能な唯一のXMLスキーマではありません。代わりにhttp://relaxng.org/を使用してください。 RelaxNGでは、さらに別のデータ「言語」を学習する必要なく、スキーマをXMLで表現できます。 XSDのように。

XMLの開発の重要な理由は、任意の数のコンピューターシステム間でデータを交換するための広く受け入れられた標準になったため、より多くのソースからより多くの方法でデータを使用できることです。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top