C ++ / CLI DLL и ObservableCollections в составном классе

Question

Я реализую библиотеку классов C ++ / CLI, которая выполняет низкоуровневую работу с устройствами и предоставляет несколько управляемых классов.Эта библиотека собирается использоваться несколькими WPF-проектами на C #.

Один из классов (называемый CalibrationRecord) состоит из нескольких открытых свойств, и некоторые из них являются коллекциями, в настоящее время реализованными в виде общих списков.Один из проектов WPF должен иметь возможность редактировать эти коллекции (т. Е. Реализовывать операции CRUD).

Я не уверен, будет ли лучше:

A.Реализуйте эти коллекции как ObservableCollections и сможете использовать их непосредственно из привязок WPF

B.Добавьте еще один слой в клиентское приложение / другую библиотеку DLL и оберните CalibrationRecord в ObservableCalibrationRecord, где коллекции являются ObservableCollections, а свойства реализуют INotifyPropertyChanged

Я думаю, что B является "более чистым" решением, поскольку в этом случае моя библиотека lib не знаетИнтерфейсы и классы, связанные с WPF, однако, было бы много дополнительной работы для реализации этого уровня, и это был бы просто скучный шаблонный код, так что А. кажется заманчивым.

Какое решение вы бы порекомендовали?Или, может быть, мне не хватает более простого решения?

Answer 1

Личные анекдоты / мнения только здесь - но я бы также порекомендовал вариант В. ObservableCollections в ваших объектах Model может быть излишним - ObservableCollection может вызывать много уведомлений, которые вам могут не понадобиться (так как коллекция может не просматриваться в это время), и кажется, что бизнес-код размыт вашим кодом пользовательского интерфейса.

Одна проблема, с которой я столкнулся лично при использовании настройки, аналогичной вашей опции B, где данные хранятся как в List, так и в ObservableCollection, заключается в том, хотите ли вы получить копию данных List в ObservableCollection или собственно объект данных самой модели. Очевидно, что если у вас есть фактические данные в ObservableCollection, то, когда пользователь обновляет объект модели, он будет повторно выбран в вашем Списке; однако вы можете столкнуться с некоторыми конструктивными ограничениями, в которых объект Model требует обработки NotifyPropertyChanged и т. д., что может отменить некоторые цели разделения этих двух. В противном случае вы должны взять объекты в ObservableCollection и синхронизировать их обратно в Список.

Я закончил с подходом синхронизации, хотя это потребовало немного дополнительной работы, когда пользователь закончил редактирование. В конце концов, разделение между ними сохранило код редактирования пользовательского интерфейса, отделенный от кода / объектов бизнес-операций, что того стоило.