我想實驗性地應用一次我讀過的封裝方面，其中一個實體對象包含其屬性的域，例如，對於其CostCentre屬性，它包含有效成本中心的列表。這樣，當我打開一個擴展的編輯表單時，我只需要傳遞一個擴展對象的形式，其中我通常在初始化表單時訪問一個CostCentre對象。實體框架和封裝
這也適用於我有一個綁定到網格（telerik RadGrid）的擴展列表，並且我處理網格上的編輯命令。我想創建一個編輯表單並將其傳遞給一個擴展對象，現在我將編輯表單傳遞給一個ExtensionID並在表單中創建我的對象。
我在這裏實際問到的是指示這樣做的指導，或者是實現類似於我在此描述的東西的「正確」方式。
這取決於您的數據源。如果您從數據庫中檢索成本中心清單，那將是一種方法。如果它是一個預定值的簡短列表（如Yes/No/Maybe So），那麼屬性屬性可能會訣竅。如果每個環境需要更多配置，那麼IoC或Provider模式將是最佳選擇。
我認爲你的問題類似於我們在前一個項目中做的自定義特設搜索頁面。我們使用包含一些預先定義的指向查找值方法的指針及其關係的屬性來修飾實體類和屬性。然後我們創建了一個自定義的UI控件（比如你的文章中描述的編輯頁面），它使用這些屬性通過動態生成一個LINQ表達式來生成下拉列表和自動完成文本框列表，然後在運行時根據無論用戶在做什麼。
這基本上是由三個移動部分完成的：A）數據訪問對象的屬性B）中間層編譯和生成動態LINQ表達式的'屬性外觀'方法和C）調用自定義UI控件我們的中間層服務方法。
有時候計劃會像這些逆火一樣，但在我們的案例中它效果很好。用屬性裝飾我們的對象，然後創建一條邏輯路徑，使我們有足夠的能力做我們需要做的事情，同時最大限度地減少所需的代碼量，並完全消除任何樣板。但是，這種方法不是非常可配置的。通過將這些屬性編譯到代碼中，我們將應用程序與數據源緊密耦合。在這個特定的項目中，這不是什麼大問題，因爲它是一個客戶內部系統，它適合項目時間表。然而，在一個用「Provider」模式實現邏輯的「真實產品」上，或者使用像Castle Projects這樣的東西，IoC可以讓我們擁有同樣的能力，並具有更多的可配置性。這樣做的缺點是需要管理更多，以及更多的部署可能會出錯等。