Home/ Questions/Q 3634684
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T00:48:35+00:00

I’m implementing a C++/CLI class library that does some low-level device-related stuff and exposes

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0