DataContract の代わりに XmlSerialization を選択した場合の主な制限など、後で後悔する可能性があるものはありますか? これまでは、スキーマ ファースト コントラクトの設計を採用してきました。
たとえば、パラメーター検査、セキュリティ強化などを行いたい場合、他の WCF 機能を追加しようとすると、XmlSerialization でロックインすることが問題になりますか?
DataContract の代わりに XmlSerialization を選択した場合の主な制限など、後で後悔する可能性があるものはありますか? これまでは、スキーマ ファースト コントラクトの設計を採用してきました。
たとえば、パラメーター検査、セキュリティ強化などを行いたい場合、他の WCF 機能を追加しようとすると、XmlSerialization でロックインすることが問題になりますか?
DataContractSerializer要素など、特定のスキーマ要素は でサポートされていませんxs:choice。これらのサポートされていない要素のいずれかを使用することになった場合、必要に応じてデータ コントラクトに切り替えるのは非常に困難になることに注意してください。
それとは別に、DataContractSerializervs . XmlSerializer hereのかなり良い内訳があります。おそらく最も重要なポイントは次のとおりです。
DataContractSerializer通常はより効率的です。DataContractSerializerフィールドをシリアル化できます (XmlSerializerプロパティが必要です)。XmlSerializerシリアル化されたプロパティごとにpublic のgetterとsetterが必要です (これは非常に煩わしく、次善の設計につながる可能性があります)。XmlSerializerパラメーターなしのパブリック コンストラクターが必要です (DataContractSerializer実際には無視されます)。XmlSerializerはデフォルトでオプトアウトですが、DataContractSerializerオプトインです。XmlSerializer従来のクライアント (つまり、ASMX Web サービスやその他のプラットフォーム) と相互運用できる可能性が高くなります。一般に、XmlSerializerを使用すると XML をより細かく制御できますが、を使用するとコードDataContractSerializerをより詳細に制御できます。XML シリアライザーを使用する場合は、気まぐれにコーディングする必要がありますが、データ コントラクトはほぼすべてのコードと統合できます。