我想实验性地应用一次我读过的封装方面，其中一个实体对象包含其属性的域，例如，对于其CostCentre属性，它包含有效成本中心的列表。这样，当我打开一个扩展的编辑表单时，我只需要传递一个扩展对象的形式，其中我通常在初始化表单时访问一个CostCentre对象。实体框架和封装
这也适用于我有一个绑定到网格（telerik RadGrid）的扩展列表，并且我处理网格上的编辑命令。我想创建一个编辑表单并将其传递给一个扩展对象，现在我将编辑表单传递给一个ExtensionID并在表单中创建我的对象。
我在这里实际问到的是指示这样做的指导，或者是实现类似于我在此描述的东西的“正确”方式。
这取决于您的数据源。如果您从数据库中检索成本中心清单，那将是一种方法。如果它是一个预定值的简短列表（如Yes/No/Maybe So），那么属性属性可能会诀窍。如果每个环境需要更多配置，那么IoC或Provider模式将是最佳选择。
我认为你的问题类似于我们在前一个项目中做的自定义特设搜索页面。我们使用包含一些预先定义的指向查找值方法的指针及其关系的属性来修饰实体类和属性。然后我们创建了一个自定义的UI控件（比如你的文章中描述的编辑页面），它使用这些属性通过动态生成一个LINQ表达式来生成下拉列表和自动完成文本框列表，然后在运行时根据无论用户在做什么。
这基本上是由三个移动部分完成的：A）数据访问对象的属性B）中间层编译和生成动态LINQ表达式的'属性外观'方法和C）调用自定义UI控件我们的中间层服务方法。
有时候计划会像这些逆火一样，但在我们的案例中它效果很好。用属性装饰我们的对象，然后创建一条逻辑路径，使我们有足够的能力做我们需要做的事情，同时最大限度地减少所需的代码量，并完全消除任何样板。但是，这种方法不是非常可配置的。通过将这些属性编译到代码中，我们将应用程序与数据源紧密耦合。在这个特定的项目中，这不是什么大问题，因为它是一个客户内部系统，它适合项目时间表。然而，在一个用“Provider”模式实现逻辑的“真实产品”上，或者使用像Castle Projects这样的东西，IoC可以让我们拥有同样的能力，并具有更多的可配置性。这样做的缺点是需要管理更多，以及更多的部署可能会出错等。