我正在实现一个 C++/CLI 类库，它执行一些与设备相关的低级工作并公开一些托管类。这个库即将被一些 C# WPF 项目使用。
其中一个类(称为 CalibrationRecord)包含一些公共(public)属性，其中一些是集合，目前实现为通用列表。 WPF 项目之一必须能够编辑这些集合(即实现 CRUD 操作)。
我很困惑是否会更好:
A. 将这些集合实现为 ObservableCollections，并能够直接从 WPF 绑定(bind)中使用它们
B. 在客户端应用程序/另一个DLL中添加另一个层并将CalibrationRecord包装在ObservableCalibrationRecord中，其中集合是ObservableCollections，属性实现INotifyPropertyChanged
我认为 B 是一个“更干净”的解决方案，因为这样我的类库不知道 WPF 相关的接口(interface)和类，但是，实现这一层还有很多额外的工作，而且它只是简单无聊的样板代码，所以 A 看起来很诱人。
您会推荐哪种解决方案？或者，也许我错过了一些更简单的解决方案？
最佳答案
个人轶事/意见只在这里 - 但我也推荐选项 B。您的模型对象中的 ObservableCollection 可能是矫枉过正 - ObservableCollection 可以引发许多您可能不需要的通知(因为当时可能无法查看该集合)并且似乎使您的 UI 代码模糊了业务代码。
我在使用与您的选项 B 类似的设置时遇到的一个问题，其中数据存储在 List 和 ObservableCollection 中，是您是否想要 ObservableCollection 中的 List 数据副本或实际模型数据对象本身。显然，如果您在 ObservableCollection 中有实际数据，那么当用户更新模型对象时，它将反射(reflect)在您的列表中；但是，您可能会遇到一些设计约束，其中 Model 对象需要 NotifyPropertyChanged 处理等 - 这可能会破坏将两者分开的某些目的。否则，您必须获取 ObservableCollection 中的对象并将它们同步回列表。
我最终选择了同步方法，尽管当用户完成编辑后这需要一些额外的工作。最终，两者的分离使UI编辑代码与业务操作代码/对象划定，这是值得的。
关于wpf - 复合类中的 C++/CLI DLL 和 ObservableCollections，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4616101/