2

I need a BindingList in my UI to provide two-way databinding between my collection and a DataGridView. However, it doesn't seem correct to return a BindingList from your business layer (or domain layer, service layer, data layer, etc.). That is, I'd only be using a BindingList because of a UI requirement, and now this UI need would be coupled with my domain layer.

What is the "proper" decoupled way to do this? Should I be returning an IList and then copying it into a BindingList for presentation purposes? From a real world perspective, is this overhead worth anything?

4

4 回答 4

2

没有 IList 的复制（至少我希望您不是真的想要创建副本/克隆）。您通常所做的只是在同一个 IList 对象上创建另一个引用。所以返回一个 IList 对象没什么不好。

例如，您可以从 bindingList（位于您的 UI 中）返回一个 List 对象并引用它。

在我看来，返回 IList (List, HashTable aso) 对象比返回 BindingList 对象更好，因为您可以在不同的 UI（控制台、Web、Win、Service）上使用前者。例如，在 Web 应用程序中使用 bindingList 不会有任何优势。

于 2011-01-13T19:25:07.210 回答
1

我不知道“正确”的方式是什么，但我过去曾使用过像 CSLA 这样的框架，而且我知道它使用了 BindingList 和现在的 ObservableCollection 用于业务列表。这使得在 UI 中使用业务对象变得非常简单，因为当从列表中添加或删除项目时 UI 会更新。如果返回 IList，然后将其复制到 BindingList 中，则需要手动监视和处理 IList 的更改并将这些更改转换为 BindingList。我个人的偏好是尽可能拥有一个功能丰富的业务层，它将使用 BindingList 或 ObservableCollection 将业务层呈现给 UI。

于 2011-01-13T18:31:23.053 回答
0

如果您希望 UI 元素在不实现自己的事件处理程序的情况下编辑业务模型，则业务模型必须具有 BindingList。

每当您执行类似new BindingList<MyWidget>( list )将绑定与根列表分离的操作时。如果一个项目被编辑，它会一切正常，但添加和删除不会反映在原始列表中。

我最近尝试通过利用 BindingList 事件来实现类似的东西，该ListChanged事件更新了我的模型以反映 BindingList 更改，但如果控制器更改了模型，它不会更新 UI 中的 BindingList。

您可以为列表生成特殊访问器，每次在列表中添加或删除项目时都会引发事件，但这只是重新发明了 BindingList 轮子，开销更大。

于 2013-03-15T21:27:45.997 回答
0

我认为域层将返回更通用的类型，并且它们是否通知（ObservableCollection<>或IEnumerable<>）IList<>是否符合要求。

如果需要该功能，UI 层可以根据需要（或不希望）将它们转换为 IBindingList。

我们已经使用BindableLinq取得了巨大成功，以在 UI 层实现通知/同步绑定列表（可能带有过滤器）的目标。

于 2011-01-13T19:34:03.120 回答