我在Windows窗体应用程序上工作了很长一段时间，而且我真的发现自己在GUI代码中做的更多类型转换比我在底层业务代码中做的更多。.NET中的强类型控件
我的意思是，如果你看ComboBox控件接受一些模糊的“对象”，因为它的项目变得明显。 然后你就可以显示一些DisplayMember和一个ValueMember等等。
如果我想稍后检索该值，我需要将我的对象转换回原来的样子。就像用绳子所获得的价值需要
string value = (string)combobox1.SelectedItem;
由于在框架仿制药很长一段时间，现在，我仍然不知道为什么在地狱不是从标准工具箱一个控制是通用的。
我也发现自己一直使用ListViewItems上的.Tag属性来保持显示的域对象。但每次我需要访问该对象时，我都需要另一个类型转换。
为什么不能我只是创建一个组合框或ListView类型的ListViewItem的项目
我在这里失去了一些东西，或者这仅仅是通过控制不完全深思熟虑的一个例子吗？
我不认为你错过了任何东西。 只是这些类是在泛型前期创建的，而WinForms根本没有足够的优势让MS花费大量时间来更改或扩展API。
我经常为控件创建包装类。这使我可以使用泛型。这通常与Reflection一起使用，它在编译时不是类型安全的，但可以在运行时。
我认为，这个问题的一个常见原因是不会将您的视图/表示逻辑与内存中的数据模型逻辑分开。不幸的是，这是WinForms和Visual Studio GUI设计者共同面临的体系结构错误。
WinForms和VS设计人员不鼓励程序员将其数据对象的管理与表单类本身分开。如果ComboBox ListViewItem对象不通过泛型或对象集合提供对任意对象的任何支持，情况可能会更好。
除非您一起使用有限的使用和生命周期，否则应尽量避免存储直接在您的控件或表单中引用单个数据对象。它们应该分开管理，如果需要引用它们，则应该通过为您正在使用的特定类型的视图类设计的模型管理类来完成。
尽管如此，对于该问题的简单绷带绷带可能是使用Form类上的Dictionary字段成员将您放置到ComboBox或ListView中的文本表示映射到原始对象。这不是一个理想的解决方案，但是在数据和用户界面控件之间至少有一个间接的步骤，这可以让你的代码更容易维护。
编辑：这被公认是与ListViewItemCollection类公开的Object实例分开的......正式的防御可能是他们想要支持标准的IEnumerable和ICollection接口。但是没有理由他们也不能提供这些方法的特定于类型的覆盖，因为它被设计为显式地存储ListViewItem实例。所以我对这个问题没有答案。
那么，如果你的数据绑定你的控件到DataBindingSource，你可以通过这种方式获得你的数据，但是AFAIK仍然没有强类型。如果您显示单个业务对象的多个参数/方面，则可以将其绑定到该对象，然后访问（强类型）成员 - 当然，这一切都可以追溯到Turbulent Intellect的答案，这更好地分离模型和视图。不过，我同意基于泛型的打字会有所帮助。
这是可能的（如果你愿意，你可以制作自己的通用控件），但是如果你这样做，Visual Studio自带的表单设计器将会吓倒。如果没有它，你将不得不做。
您不是第一个想到这一点的人，而且微软已经收到了公众对此的公平批评。希望他们在未来增加对此的支持。