2

エンティティでのCRUD操作をサポートするRESTfulAPIがあります。すべてのCRUD操作のスキーマを定義する単一のxsdファイルが必要ですか？

この質問をする理由は、Retrieve呼び出しにのみ関連し、CreateまたはUpdateには関連しないフィールドがいくつかあるためです。その場合、1つのxsdファイルを用意し、作成と更新の一部のフィールドを無視する必要がありますか？

4

3 に答える 3

2

あなたの質問は、フィールドの使用と XSD ファイルの数を結び付けているようです。これにより、いくつかの基本的な XSD の概念が欠けている可能性があると思います。

問題は、特定のエンティティに対して、更新できるよりも多くのフィールドを取得する可能性があることだとしましょう。架空のPersonエンティティについて説明すると、 、、および属性をR (取得) することができますが、エンティティをC (処理) するには、 のみを許可し、 - バックエンド システムに属性を設定させたいとします。要件は、モデルの自己記述性を向上させるために、XSD を可能な限り制約することです。NameAddressDate of BirthRegistered SinceNameAddressDate of BirthRegistered Since

これらのシナリオを分離するには、XSD ベース タイプを作成し、それを別のタイプを使用して拡張します。これにより、必要な追加フィールドが含まれます。この種のものは、1 つのファイルで実行することも、2 つ以上の異なるファイルで実行することもできます。

<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <xsd:complexType name="PersonBase">
        <xsd:sequence>
            <xsd:element name="Name"/>
            <xsd:element name="Address"/>
            <xsd:element name="DateOfBirth"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="PersonToRetrieve">
        <xsd:complexContent>
            <xsd:extension base="PersonBase">
                <xsd:sequence>
                    <xsd:element name="RegisteredSince"/>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
</xsd:schema>

注: 上記の XSD は、XSD のベスト プラクティスを説明することを意図したものではありません

お使いの環境で拡張/制限が許可されていない場合は、そのおかげで再利用を実現できますxsd:group-それは私の主張を変えません. したがって、私は基本的に、質問をしている理由はI have some fields that are relevant only for Retrieve calls and not for Create or Update.、XSD ファイルの数とはまったく関係がないと言っています...より多くの変数を考慮しない限り。頭に浮かぶいくつかを試してみますが、完全なリストを提供するつもりはありません。

  • 複雑さ: 解決しようとしている問題が単純な場合は、解決策を単純に保つようにしてください。上記のように、1 つの XSD ファイルを使用して「記述性」の問題を解決できます。ツールを問題領域の一部と見なすと、多くのツールには XSD 間の複雑な関係に関する問題があります... xsd:include がサポートされていないこともあり、コマンド ラインがより複雑になります。
  • XML 名前空間: 私や他の多くの人のように、ビジネス ドメインを記述する構造と、API 定義とメッセージングをサポートする構造とを分離したい場合は、異なる XML 名前空間を使用するのが一般的なソリューションです。使用することに決めた XML 名前空間と少なくとも同じ数の異なる XSD ファイルが必要です。これにより、複数の XSD ファイルが必要になります。
  • 再利用可能なコンテンツ: XSD コンテンツはさまざまな方法で再利用できます。多くのプロジェクト/インターフェースに適用したい基本的な型システムがある場合は、それらを 1 つ以上の個別の XSD ファイルで作成し、他のより具体的な XSD によってインクルード/インポートすることをお勧めします。
  • XML スキーマ リファクタリング: 人々が自動リファクタリングを使用する環境にいる場合、答えは次のようになります:誰が気にしますか? 私は、初心者がこの答えを大げさだと感じていることを直接知っています。しかし、実際には複雑なシステムを使用している場合、個人的な好み (コード/モデルのレビューなど) やさまざまなレベルのサポートを備えたさまざまなツール/プラットフォームのために、質問に対するいくつかの解決策を実際に扱うのは非常に困難です。 XSD からコードへの変換が含まれているため、XSD のリファクタリングが、物事をスムーズに実行し続ける唯一の方法である可能性が最も高いです。
于 2012-08-20T17:09:14.233 に答える
0

呼び出しごとに異なるフィールドがある場合は、異なる XSD ファイルを使用する必要がありますが、CRUD 操作に応じて一部のフィールドのみを空白のままにする場合は、別のファイルを作成する必要はありません。未使用のフィールドはそこにありますが、空白のままになります。

于 2012-08-17T22:17:46.767 に答える
0

操作に応じて、次のいずれかの方法でフィールドを処理できます。

  • 必須- 提供され、有効である必要があります。
  • オプション- このフィールドは、指定されて有効な場合にのみ使用されます。
  • 無視- サーバーはこのフィールドを無視します。たとえば、create Customer 操作の場合、ID フィールドと createdOn フィールドはクライアントによって設定できず、サーバーによって無視されます。

単純な状況では、単一のスキーマ要素を使用してエンティティを定義します。ドキュメント内のフィールドの実際の使用法について説明します。

異なる操作によるエンティティの使用法に大きな違いがある場合、別個のエンティティが適切な場合があります。たとえば、管理者の顧客取得操作では、通常のユーザーが利用できるよりもはるかに多くの顧客情報が返される場合があります。この差が大きい場合は、個別のエンティティを定義すると、それぞれにとって簡単になります。スキーマ拡張を使用して基本エンティティを拡張したり、基本エンティティからフィールドをコピーして貼り付けたりすることができます。

PS。ほとんどの Web サービス スタックは、少なくとも JAX-RS と JAX-WS では、デフォルトでスキーマ コンプライアンスを強制しません。Web サービス コード内のフィールドの有効性を確認することをお勧めします。

于 2012-08-24T13:45:53.637 に答える