クライアントがバックエンドのより複雑なメッセージング API へのファサードとして機能する Web API サービスを作成しています。バックエンド API に対して行う必要のある呼び出しを表す .XSD は、明らかに理解してもらいたいものではありません。私の目標は、クライアントが使用できる ViewModel クラスで必要な要素を平坦化することです。私のPOSTは以下のようなものかもしれません:
public HttpResponseMessage Post(FlattenedViewModel flattenedViewModel)
{
}
フラット化されたビュー モデルの考え方は、クライアントが API を呼び出すためにデータの複雑な構造を理解する必要がないようにすることです。これを送信する方がはるかに簡単です (JSON または XML の可能性があります):
<PersonFirstName>John</PersonFirstName>
<PersonLastName>Smith</PersonLastName>
<PersonPhone>123-456-7890</PersonPhone>
これより:
<Person>
<Name>
<FirstName>John</FirstName>
<LastName>Smith</LastName>
</Name>
<Communication>
<Type>
<Phone>123-456-7890</Phone>
</Type>
</Communication>
</Person>
2 番目の例を表すクラス構造を作成することは難しくなく、私たち全員にとって簡単に理解できることを理解しています。ただし、私の実際の .XSD は、この例の約 50 倍です。私の目標は、より簡単なインターフェイスとフラットなビューを持つ機能を提供することです。それをこの質問の制約として使用してください。ユーザーがフォームにデータを入力し、送信を押したとします。フォームは、入力するデータの平面図のようなものです。
私が遭遇しているハードルは次のとおりです。
有限回のセットを繰り返すことができるノードを持つことは解決可能です。ただし、.xsd に次の制約があるノードは、
maxOccurs="unbounded"
最初は平坦化されたビューでは実行できないようです。コレクションを紹介する必要がないように、これを行う別の方法はありますか? または、コレクションを導入しても、ユーザーが複雑な構造を理解する必要がないようにすることはできますか (私の最初の例のように)? 可能であれば、それがどのように見えるかの例を提供してください。.xsd のさまざまな部分で繰り返されるノード名がありますが、関連はありません。たとえば、ノード
ID
またはDate
.SubmitDate
私の解決策は、親ノード名を値に追加して、またはのようなプロパティを作成することPersonID
です。私が今抱えている問題は、ViewModel クラスのプロパティ名が、ドメイン モデルでマップする必要があるエンティティの名前と一致しないことです。私は ValueInjecter を使用していますが、別の名前 (つまり、注釈など) を持つ他のクラスにプロパティをマップできる合理化された方法はありますか?
どんな助けでも大歓迎です、ありがとう!