例如，假设我正在编写一个允许用户设计自己的名片的应用程序，允许他们将视觉对象添加到他们当前正在设计的“模板”中，这些对象中的每一个都绑定到不同的用户位-数据。
例如。他们拖动一个“地址框”，它会自动输入用户的地址，然后是一个“名称文本”，它再次自动使用用户定义的名称。
这样做的原因是客户可以创建 15 个模板，所有模板都有自己的“外观”，但是如果他们想更改地址，他们只需要在一个地方进行修改。
所有这些可视对象和模板本身都是用 XAML 编写的。我需要将这些用户创建的模板存储到数据库中，以便他们可以检索它们并在以后进行编辑。在我看来，我有两个选择：
将整个模板作为 XAML 存储在名为“模板”的数据库表中，并带有 ID 和 OwnerID。
为抽象类型的“视觉对象”创建一个表。为每个具体类型的可视对象（即“地址框”）创建一个表，该表将从抽象类型继承，并具有每个用户可配置属性（字体大小、x/y 坐标等）的字段。最后，创建一个名为模板的表，其中包含视觉对象的集合。
应该注意的是，我一直在使用实体框架来设计它，所以如果我在其中抛出了一些 EF 关键字，我们深表歉意！
就个人而言，目前 XAML 存储可能足以满足我们的要求，但是我所看到的一切似乎表明这是在数据库中存储数据的一种非常糟糕的方式.. 即。跳到 35 分钟：http://youtu.be/uFLRc6y_O3s 这不正是他建议不要做的吗？
使用 XAML 存储，我获得了属性值继承，这可能会使事情变得稍微容易一些，尽管我不确定用户是否会理解值如何沿链“流动”。显然 XAML 还允许我存储我喜欢的任何属性值；我不必先将其添加到数据库中。
缺点是我认为如果都是 XAML，管理数据可能会困难得多。最坏的情况可能不得不检索每一块 XAML，解析所有这些，找到我需要更改/查看的值，重新解析，保存更新的 XAML 的“blob”。这显然会导致更大的读/写操作。