存儲UI信息的位置

Question

假設我們有一個用於編輯小部件的窗體。給定的Widget有一個屬性。該屬性（A）的值可以是存儲的屬性列表（1,2,3）中的一個。我們的屬性列表在多個Widget類型中使用。

現在，從數據的角度來看，給定的Widget可以具有任何列表的屬性A（可以包含值1,2或3）。但是，我們的業務規則規定，Widget類型X不能包含屬性A中的值1.

我的問題是，我在哪裏存儲表單將用於填充屬性A列表的信息？

現在，碰巧我使用的是一個不同的窗體小部件X，Y和Z，但理論上，我們可能必須在同一個窗體上解決這個問題。我可以將它存儲在Widget類或Attribute類中，但是我覺得這並不代表實際的對象信息（「壽司」不是有效的Dog類食物，即使它是完全有效的食物，它沒有形容狗）。你如何填寫Edit Dog表單上的食物列表？我需要批准的列表信息是可編輯的，而不需要重新部署代碼，因爲用戶反覆無常，最終有人會想要喂他們的狗壽司。

在C＃中編寫這個，但我覺得這個問題是非常不相關的語言。

新增用戶從藍莓響應後：

謝謝，也許我的描述是不明確的。設想一個Widgets表，一個Attributes表和一個Widget_Attributes表，它們將是一個x-ref，其中包含的屬性允許被分配給一個Widget的給定屬性。這是它可以完成的一種方式，但看起來像是一種代碼味道，因爲它可能會導致Widget上每個屬性的x-ref表。所以我正在尋找一種方法來填充只有該類型的小部件允許的屬性值的控件。

現在領先的想法是將標誌枚舉添加到每個屬性記錄中，以指示屬性對哪些小部件有效。在Dog-Food示例中，Food壽司將具有值爲1的EatenBy枚舉屬性，其中枚舉將被定義爲Human = 1，Dog = 2，Cat = 4。

Answer 1

如果我理解您的問題是否正確，您是否擁有一個基於您的控件的另一部分中的用戶選擇的數據具有不同行爲的小部件？

首先，我不認爲這是正確的或錯誤的答案。它真的取決於用戶界面與邏輯的距離。如果它以任何方式處理業務邏輯，我會保持它不受控制（比如說一個組合框），但是，如果它的純粹的UI（如在日期時間選擇器中說的邏輯），它將進入控制。

儘管它的聲音，從我從你的具體案例收集，它是第一個更接近。如果您使用的是MVC體系結構，那麼我可能會將此邏輯與我的視圖或控制器相比更接近我的模型。

我想這只是一個更復雜的說，一個組合框會做什麼，我會說肯定爲了保持這個通用，它不會是形式的一部分或控制自己，因爲這將是相當一個具體的案例。或許只有你會使用代碼，但在一般的編碼實踐中，將這些細節保留在你的控件之外，至少可以實現更好的代碼重用。

根據數據的複雜程度，您可以做的是創建一個對象，其中包含所有這些數據，在模型上創建它並將其傳遞給小部件，以便知道在各種組件您的控件的數據由用戶選擇。 I.E.控件可以理解但在模型上生成的對象。如果數據足夠靜態，它不是必須回調模型，這可能會在初始化時傳遞。

希望有幫助，只是我的看法。