假设我们有一个用于编辑小部件的表单。给定的Widget具有属性。该属性（A）的值可以是存储的属性列表（1,2,3）之一。我们的属性列表用于多种Widget类型。
现在，从数据的角度来看，给定的Widget可以具有任何列表的属性A（它可以包含值1,2或3）。但是，我们的业务规则规定Widget类型X不能包含属性A中的值1。
我的问题是，我在哪里存储表单用于填充属性A列表的信息？
现在，我正在为Widgets X，Y和Z使用不同的表单，但理论上，我们必须在同一表单上解决这个问题。我可以将它存储在Widget类或Attribute类中，但我觉得这不能代表实际的对象信息（就像“寿司”不是Dog类的有效食品一样，即使它是完全有效的食物，它没有描述狗）。您将如何填写编辑狗表格上的食物清单？我需要批准的列表信息是可编辑的，而不需要重新部署代码，因为用户变幻无常，最终有人会想要喂他们的狗寿司。
在C＃中写这个，但我觉得这个问题与语言无关。
在蓝莓用户回复后添加：
谢谢，也许我的描述不清楚。想象一下Widgets表，Attributes表和Widget_Attributes表，它将是一个x-ref，其中包含要分配给Widget的给定属性的Attributes allowed 。这是可以做到的一种方式，但看起来像代码味道，因为它可能导致Widget上每个属性的x-ref表。所以我正在寻找一种方法来填充一个只有该类型小部件允许的属性值的控件。
现在领先的想法是为每个属性记录添加一个标志枚举，以指示属性有效的小部件。在Dog-Food示例中，Food sushi将具有值为1的EatenBy枚举属性，其中枚举将定义为Human = 1，Dog = 2，Cat = 4.
答案 0 :(得分：0)
如果我理解你的问题，你有一个小部件根据用户在你控件的另一部分选择的数据有不同的行为吗？
首先，我不认为对此有正确或错误的答案。这真的取决于逻辑UI的接近程度。如果它以任何方式存在业务逻辑，我会让它不受控制（比如说是一个组合框），但是，如果它纯粹是UI（比如说日期时间选择器中的逻辑），它就会进入控件。
通过它的声音，从我从你的具体案例中收集到的，它比第一个更接近。如果您使用的是MVC架构，那么我的模型可能比我的视图或控制器更接近我的模型。
我想这只是一个更复杂的版本，比如ComboBox会做什么，我会说当然为了保持这种通用性，它不会是表单或控件本身的一部分，因为它会相当具体案例。可能只有你将使用代码，但在一般的编码实践中，将这些细节保留在控件之外将至少可以更好地重用代码。
根据数据的复杂程度，你可以做的是创建一个包含所有这些数据的对象，在模型上创建它并将其传递给小部件，以便它知道当各种组件时要做什么您的控件的数据由用户选择。 I.E.控件将理解但在模型上生成的对象。如果数据足够静态，则不一定要回调模型，这可能会在初始化时传递。
希望这有帮助，只是我的观点。