什么方法被认为是保持 GUI 控件内的数据结构与应用程序维护的数据结构同步的“标准”？
例如: 在 WinForms 中，如果创建一个 ListView 实例，而不是将其指向表示要出现在列表中的项目的数据结构，则必须以编程方式实例化 ListViewItem(s) 并调用 .Add 方法来手动复制它们，一个接一个, 转换为 ListView 本身内部的数据结构。从线程的角度来看，这是有道理的，而且在呈现的上下文中，控件应该需要专门的数据结构存在，控件本身就知道有关维护的详细信息。
但是，这会产生两个问题:
冗余: 如果客户端类管理自己的实体列表，以允许用户从 WinForms UI 中选择它们，则必须读取、转换整个列表，然后通过以下方法在 UI 控件内部重新创建:.Add(ListViewItem item ) 列表现在占用两倍的内存。
复杂性: 由于现在存在两个列表，因此必须以编程方式确保它们保持同步。这可以通过从客户端类的集合对象触发的事件来实现，或者程序员可以简单地小心地在一个列表中添加/删除另一个列表时始终添加/删除。
我见过很多这样的例子，程序员会采取快捷方式使用 UI 元素(如 ListView)作为用于维护列表的实际集合对象。例如，每个用户输入的项目将立即插入到 ListView 中，然后当需要访问用户的全部内容时，应用程序只需遍历 ListView。当您正确地将业务/应用程序逻辑与 UI 逻辑分开时，此方法将无法应用。
总的来说，将应用程序数据存储在 GUI 控件内部的数据结构中似乎有些不对。同样，存储两个列表并以编程方式使它们保持同步似乎也不是一个优雅的解决方案。理想情况下，人们只需要提供一个 UI 元素，其中包含对驻留在客户端范围内的列表的引用。
那么，解决这个问题的“正确”方法是什么？
最佳答案
每个 UI 控件都需要一些自己的状态。对于复杂的控件(如 ListView)，状态相应地复杂。诀窍是使控件状态的维护尽可能简单。使用标准的 ListView，这是不可能的——程序员必须完成这项工作。
这就是我写 ObjectListView 的原因之一(围绕 .NET WinForms ListView 的开源包装器)。它允许您在更高级别使用 ListView，其中控件状态的维护是不可见的。 ObjectListView 直接对您的模型对象进行操作:
this.objectListView1.Objects = listOfModelObjects;
this.objectListView1.SelectedObject = aPerson;
一旦您可以在这个级别上工作，数据绑定(bind)本身就没有那么有用了。但是，如果你真的想使用它，你可以使用 ObjectListView 中的可绑定(bind)数据的 DataListView。项目。它让您两全其美。
有了 ObjectListView，就没有理由切换到有趣得多的 DataGridView。 ObjectListView 为您提供了 DataGridView 的便利性和 ListView 的良好 UI 功能，然后还有更多:
关于c# - 应该如何在 WinForms GUI 控件和客户端类之间同步数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1676466/