是否將XAML存儲在數據庫不良設計中？

例如，說我編寫的應用程序，允許用戶設計自己的名片，使他們能夠可視化對象添加到「模板」，他們目前正在設計，每個對象綁定到的各個位用戶數據。是否將XAML存儲在數據庫不良設計中？

例如。他們拖動一個自動放入用戶地址的「地址欄」，然後拖動一個「名稱文本」，它再次自動使用用戶定義的名稱。

這樣做的原因是，客戶可以創建15個模板都用自己的「看」，但如果他們想改變他們的地址，他們只需要修改它在一個地方。

所有這些視覺對象和模板本身的，都寫在XAML。我需要將這些用戶創建的模板存儲到數據庫中，以便以後可以檢索它們並進行編輯。我看到它的方式，我有兩個選擇：

存儲整個模板XAML數據庫中的表稱爲「模板」與ID和OWNERID一起。
用於抽象類型「視覺對象」的創建一個表。爲每個具體類型的可視對象（即「AddressBox」）創建一個表，該表可以繼承抽象類型，併爲每個用戶可配置屬性（字體大小，x/y座標等）設置字段。最後，創建一個名爲template的表格，該表格包含可視對象的集合。

應當指出的是，我一直在使用實體框架來設計這一點，所以如果我在那裏投入了一些EF關鍵字的歉意！

個人，暫且XAML存儲可能是足以滿足我們的要求，但是我看到的一切似乎表明它是將數據存儲在數據庫中的一個非常糟糕的方式..即。跳到35分鐘在這：http://youtu.be/uFLRc6y_O3s是不是這正是他建議不要做的？

使用XAML存儲我獲得了屬性值繼承，這可能使事情稍微容易一些，但我不確定用戶是否理解價值如何「流」下來。很顯然，XAML還允許我存儲任何我喜歡的屬性值;我不必先將它添加到數據庫中。

的缺點是，我認爲這可能是很多難以管理的數據，如果這一切都XAML;最壞的情況可能需要檢索每一片XAML，解析所有這些XAML，找到一個我需要更改/查看的值，重新解析並將更新後的「blob」保存回。這顯然會導致更大的讀/寫操作。

來源

2012-04-20 Siyfion

我會去直接存儲XAML。原因在於，您從存儲抽象佈局中獲得的唯一優勢是您可以替換UI框架，並且可以防範XAML中潛在的重大更改。但是，隨着微軟推出的突破性改變將打破所有的控制，所以會有一些升級的可能性，你很可能也會使用它。

對我來說選項2肯定是更好的版本，但我傾向於是「YAGNI」-guy。所以當你需要的時候開發一些東西，如果你在WPF上去做。

心連心，馬丁

來源

2012-04-20 10:23:51

有趣......這不是我期待在所有的響應！可維護性如何？特別是如果存儲在XAML中的類型不是普通的舊CLR對象，它們是自定義類型？另外，如果我想知道有多少人正在使用我們的「地址框」對象，不會將它存儲爲XAML使得獲取該信息更難？ – Siyfion 2012-04-20 12:03:24

現在你給自己答案，你想做什麼。我剛纔提出了我會如何處理你提供的信息。 - >這是「保持簡單」 – 2012-04-20 13:53:46

嗯，我問的主要原因是暫時XAML存儲可能足以滿足我們的要求，但是我看到的所有東西似乎都表明這是一種非常糟糕的存儲數據的方式在數據庫中..即。在這裏跳到35分鐘：http://youtu.be/uFLRc6y_O3s是不是這正是他建議*不*做的？ – Siyfion 2012-04-20 14:58:04

我會投給選項2，雖然我不知道，如果你需要單獨的表對每個具體的對象，而不必爲每個「用戶可配置屬性」的領域你可以把所有用戶可配置的屬性放在鏈接到conrete-object表的其他表中。

ConcreteObjectTable

對象ID | ObjectName | ObjectTemplate

ConcreteObjectPropertyTable

物業ID | ObjectID | PropertyName |

的PropertyValue

這樣，你只有2-3個桌子擔心配置選項

來源

2012-04-24 04:04:06

我會投票選項2了。通過這種方式進行存儲，您可以非常靈活地使用數據。

不利的一面，選項2會迫使您編寫某種解析器，它將數據解析爲XAML代碼。但是當你想要兩個相同數據的GUI（例如HTML）時，你唯一需要做的就是編寫一個HTML解析器，並且很好。另外，您要保存到數據庫的數據也會減少。

所以總結（選項2）：

優點

數據的靈活解釋

缺點

下的數據庫空間

你需要寫一個解析器爲每一個GUI實現

來源

2012-04-26 06:11:30

謝謝你的解釋@ M.Schenkel – 2014-05-09 03:19:57

是否將XAML存儲在數據庫不良設計中？

回答

相關問題