复合类中的 C++/CLI DLL 和 ObservableCollections
我正在实现一个 C++/CLI 类库，它执行一些与设备相关的低级操作并公开一些托管类。该库即将被一些 C# WPF 项目使用。
其中一个类（称为 CalibrationRecord）包含一些公共属性，其中一些是集合，当前实现为通用列表。 WPF 项目之一必须能够编辑这些集合（即实现 CRUD 操作）。
我很困惑是否更好：
A. 将这些集合实现为 ObservableCollections 并能够直接从 WPF 绑定使用它们
B. 在客户端应用程序/另一个 DLL 中添加另一层并将 CalibrationRecord 包装在 ObservableCalibrationRecord 中，其中集合是 ObservableCollections和属性实现 INotifyPropertyChanged
我认为 B 是一个“更干净”的解决方案，因为这样我的类库不了解 WPF 相关的接口和类，但是，实现这一层会有大量额外的工作，而且它只是简单乏味的样板代码，所以 A 看起来很诱人。
您会推荐哪种解决方案？或者也许我错过了一些更简单的解决方案？
I'm implementing a C++/CLI class library that does some low-level device-related stuff and exposes a few managed classes. This library is about to be utilized by a few C# WPF projects.
One of the classes (called CalibrationRecord) consists of a few public properties, and some of them are collections, currently implemented as generic Lists. One of the WPF project has to be able to edit those collections (i.e. implement CRUD operations).
I'm confused whether it would be better to:
A. Implement those collections as ObservableCollections and be able to use them directly from WPF bindings
B. Add another layer in the client app/another DLL and wrap CalibrationRecord in ObservableCalibrationRecord, where collections are ObservableCollections and properties implement INotifyPropertyChanged
I think that B is a "cleaner" solution because this way my class lib has no knowledge of WPF-related interfaces and classes, however, there would be plenty of additional work to implement this layer, and it would be just plain boring boilerplate code, so A seems tempting.
Which solution would you recommend? Or maybe I'm missing some simpler solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
个人轶事/意见仅在此 - 但我也会推荐选项 B。 Model 对象中的 ObservableCollections 可能有点过头了 - ObservableCollection 可能会引发大量您可能不需要的通知（因为当时可能无法查看该集合），并且似乎会模糊业务代码与 UI 代码。
我个人在使用与选项 B 类似的设置（其中数据存储在 List 和 ObservableCollection 中）时遇到的一个问题是，您是否想要 ObservableCollection 中的 List 数据的副本或实际模型数据对象本身。显然，如果 ObservableCollection 中有实际数据，那么当用户更新模型对象时，它将反映在您的列表中；但是，您可能会遇到一些设计约束，其中 Model 对象需要 NotifyPropertyChanged 处理等 - 这可能会破坏将两者分开的某些目的。否则，您必须获取 ObservableCollection 中的对象并将它们同步回 List。
我最终采用了同步方法，尽管当用户完成编辑后需要一些额外的工作。最终，两者之间的分离使 UI 编辑代码与业务操作代码/对象区分开来，这是值得的。
Personal anecdotes / opinion only here - but I would recommend Option B as well. ObservableCollections in your Model objects can be overkill - the ObservableCollection can raise a lot of notifications that you may not need (as the collection may not be viewed at that time) and seems to blur the business code with your UI code.
One issue I ran into personally while using a similar setup to your Option B, where the data is stored in both a List and in an ObservableCollection, is whether or not you want a copy of the List data in your ObservableCollection or the actual model data object itself. Obviously if you have the actual data in the ObservableCollection, than as the user updates the model object it will be refelected in your List; however, you can run into some design constraints where the Model object needs NotifyPropertyChanged handling, etc. - which can defeat some of the purpose of seperating the two. Otherwise, you have to take the objects in your ObservableCollection and synchronize them back to the List.
I ended up going with the synchronization approach, although that took a bit of extra work when the user was finished with their edits. In the end, the seperation between the two kept the UI editing code delineated from the business operational code / objects, which was worth it.