2011-01-06 3 views
0

일부 저수준 장치 관련 작업을 수행하고 몇 개의 관리되는 클래스를 노출하는 C++/CLI 클래스 라이브러리를 구현하고 있습니다. 이 라이브러리는 몇 가지 C# WPF 프로젝트에서 사용할 예정입니다.복합 클래스의 C++/CLI DLL 및 ObservableCollections

클래스 중 하나 (CalibrationRecord라고 함)는 몇 가지 공용 속성으로 구성되며 그 중 일부는 현재 일반 목록으로 구현 된 컬렉션입니다. WPF 프로젝트 중 하나는 해당 컬렉션을 편집 할 수 있어야합니다 (즉, CRUD 작업 구현).

나는 더 좋을 것인지 혼란 스러워요 :

는 A. ObservableCollections로 그 컬렉션을 구현하고/클라이언트 응용 프로그램에서 다른 레이어를 추가

B. WPF 바인딩에서 직접 사용할 수 다른 DLL 및 ObservableCalibrationRecord에서 ObservableCalibrationRecord를 랩핑합니다. 컬렉션은 ObservableCollections이고 속성은 INotifyPropertyChanged를 구현합니다.

이 클래스는 WPF 관련 인터페이스와 클래스에 대한 지식이 없기 때문에 B는 "클리너"솔루션이라고 생각합니다. 많을 것이다. 이 레이어를 구현하기위한 추가 작업이 필요하며 일반 보링 플레이트 코드 일 뿐이므로 A가 유혹적으로 보입니다.

어떤 솔루션을 추천 해 주시겠습니까? 아니면 좀 더 간단한 해결책이 없습니까?

답변

0

개인적인 일화/의견은 여기에 있습니다.하지만 옵션 B도 권하고 싶습니다. ObservableCollection은 필요하지 않을 수도있는 많은 알림을 발생시킬 수 있으며 (컬렉션은 그 당시에는 볼 수 없으므로) UI 코드로 비즈니스 코드를 흐리게 표시하는 것처럼 보입니다.

데이터가 List 및 ObservableCollection에 저장되는 옵션 B와 비슷한 설정을 사용하는 동안 개인적으로 한 가지 문제가 발생했습니다. ObservableCollection에 목록 데이터의 복사본을 저장할지 아니면 실제 모델 데이터 객체 자체. ObservableCollection에 실제 데이터가있는 경우 사용자가 모델 객체를 업데이트하는 것보다 분명히 List에서 다시 선택됩니다. 그러나 Model 객체가 NotifyPropertyChanged 처리 등을 필요로하는 몇 가지 설계 제약 조건을 실행할 수 있습니다. 이는 두 모델을 분리하는 목적 중 일부를 무효화 할 수 있습니다. 그렇지 않으면 ObservableCollection에서 개체를 가져 와서 목록에 다시 동기화해야합니다.

사용자가 편집을 마쳤을 때 약간의 추가 작업이 필요했지만 동기화 접근 방식이 끝났습니다. 결국, 둘 사이의 분리는 UI 편집 코드를 비즈니스 운영 코드/객체에서 묘사 된 것으로 유지하면서 그만한 가치가있었습니다.