たとえば、ユーザーが独自の名刺をデザインし、現在デザインしている「テンプレート」にビジュアルオブジェクトを追加できるアプリケーションを作成しているとします。これらのオブジェクトは、ユーザーのさまざまなビットにバインドされています。データ。
例えば。ユーザーのアドレスを自動的に入力する「アドレスボックス」をドラッグしてから、ユーザーが定義した名前を自動的に使用する「名前テキスト」をドラッグします。
これは、顧客が15個のテンプレートをすべて独自の「外観」で作成できるためですが、アドレスを変更する場合は、1か所で変更するだけで済みます。
これらのビジュアルオブジェクトとテンプレート自体はすべてXAMLで記述されています。これらのユーザー作成テンプレートをデータベースに保存して、後で取得して編集できるようにする必要があります。私の見方では、2つの選択肢があります。
テンプレート全体をXAMLとして、IDおよびOwnerIDとともに「templates」と呼ばれるデータベーステーブルに保存します。
抽象型の「ビジュアルオブジェクト」のテーブルを作成します。抽象型から継承し、ユーザーが構成可能な各プロパティ（フォントサイズ、x / y座標など）のフィールドを持つ、視覚オブジェクトの具体的な型（つまり、「AddressBox」）ごとにテーブルを作成します。最後に、ビジュアルオブジェクトのコレクションを保持するtemplateというテーブルを作成します。
これを設計するためにEntityFrameworkを使用していることに注意してください。そのため、EFキーワードをいくつかスローした場合はお詫びします。
個人的には、当面はXAMLストレージで要件を満たすのに十分かもしれませんが、私が見たすべてのことは、データベースにデータを格納するのは本当に悪い方法であることを示唆しているようです。これで35分にスキップしてください：http：//youtu.be/uFLRc6y_O3sこれは彼がやらないように提案していることではありませんか？
XAMLストレージを使用すると、プロパティ値の継承が得られます。これにより、値がチェーンをどのように「流れる」かをユーザーが理解できるかどうかはわかりませんが、少し簡単になる可能性があります。もちろん、XAMLを使用すると、好きなプロパティ値を格納することもできます。最初にデータベースに追加する必要はありません。
欠点は、すべてXAMLの場合、データの管理が非常に難しくなる可能性があることです。最悪の場合、XAMLのすべての部分を取得し、それらすべてを解析し、変更/確認する必要のある値を見つけ、再解析し、XAMLの更新された「blob」を保存しなければならない可能性があります。これにより、明らかにはるかに大きな読み取り/書き込み操作が発生します。