您是不是应该从业务层（或服务层、域模型等）返回 BindingList？
Posted
技术标签:
【中文标题】您是不是应该从业务层（或服务层、域模型等）返回 BindingList？【英文标题】：Should you return a BindingList from a business layer (or service layer, domain model, etc.)?您是否应该从业务层（或服务层、域模型等）返回 BindingList？ 【发布时间】：2011-06-08 16:32:12 【问题描述】：我的 UI 中需要一个 BindingList，以便在我的集合和 DataGridView 之间提供双向数据绑定。但是，从业务层（或域层、服务层、数据层等）返回 BindingList 似乎并不正确。也就是说，由于 UI 需求，我只会使用 BindingList，现在这个 UI 需求将与我的领域层相结合。
执行此操作的“正确”解耦方式是什么？我应该返回一个 IList，然后将其复制到一个 BindingList 中以进行演示吗？从现实世界的角度来看，这种开销值得吗？
【问题讨论】：
这个问题实际上引导我了解如何将 MVVM 与 WPF 结合使用。我刚刚开始，但我喜欢它。 【参考方案1】：没有 IList 的复制（至少我希望您不是真的想要创建副本/克隆）。您通常所做的只是在同一个 IList 对象上创建另一个引用。所以返回一个 IList 对象也没什么不好。
您可以返回，例如一个 List 对象并从 bindingList（位于您的 UI 中）中引用它。
在我看来，返回 IList (List, HashTable aso) 对象比返回 BindingList 对象更好，因为您可以在不同的 UI（控制台、Web、Win、服务）上使用前者。例如。在 Web 应用程序中使用 bindingList 没有任何优势。
【讨论】：
在 WinForms 中将 IList 与 DataGridView 一起使用，您如何建议 IList 中的更改反映在 UI 中？ 我认为您误解了我的帖子 - 您需要在 UI 层上使用 BindingList。但在领域层，我会建议 IList 或其他任何东西。只是为了说明这一点：D 啊，我明白了。关于“禁止复制”的评论，我假设您的意思是从 IList 在 UI 层中创建一个 BindingList（例如，var x = new BindingList我不知道“正确”的方式是什么，但我过去使用过像 CSLA 这样的框架，并且我知道它使用 BindingList 和现在的 ObservableCollection 用于业务列表。这使得在 UI 中使用业务对象变得非常简单，因为当从列表中添加或删除项目时 UI 会更新。如果返回 IList，然后将其复制到 BindingList 中，则需要手动监视和处理 IList 的更改并将这些更改转换为 BindingList。我个人的偏好是尽可能拥有一个功能丰富的业务层，它会使用 BindingList 或 ObservableCollection 将业务层呈现给 UI。
【讨论】：
我想我的问题是，如果您随后通过网站公开相同的数据，那么绑定列表在网络上下文中没有（或有限）使用。【参考方案3】：我认为域层会返回更通用的类型，它们是否通知（ObservableCollection<>）或不通知（IEnumerable<> 或IList<>）符合要求。
如果需要该功能，UI 层可以根据需要（或不希望）将它们转换为 IBindingList。
我们已经使用BindableLinq 取得了巨大成功，以实现在 UI 层通知/同步绑定列表（可能带有过滤器）的目标。
【讨论】：
【参考方案4】：如果您希望 UI 元素在不实现自己的事件处理程序的情况下编辑业务模型，则业务模型必须具有 BindingList。
每当您执行new BindingList<MyWidget>( list ) 之类的操作时，您都会将绑定与根列表分离。如果一个项目被编辑了，它会一切正常，但添加和删除不会反映在原始列表中。
我最近尝试通过利用 BindingList ListChanged 事件来实现类似的功能，该事件更新了我的模型以反映 BindingList 更改，但如果控制器更改了模型，它不会更新 UI 中的 BindingList .
您可以为您的列表生成特殊的访问器，每次您在列表中添加或删除项目时都会引发事件，但这只是重新发明了 BindingList ***，开销更大。
【讨论】：
以上是关于您是不是应该从业务层（或服务层、域模型等）返回 BindingList？的主要内容，如果未能解决你的问题，请参考以下文章