Указатели C ++ в C # MVVM

В настоящее время я работаю над проектом на C #, который использует библиотеки C ++. Для использования библиотек C ++ они заключены в CLR. Связь между C ++ и C # осуществляется в обоих направлениях.

У меня следующая проблема. В какой-то момент C ++ вызывает некоторые функции в CLR, которые вызывают события с объектами, имеющими необработанные указатели C ++.

Например:

C ++ объект

class CObject {
private:
char* ptr;
}

Объект CLR

ref class CLRObject {
public: CLRObject(CObject* p) : m_native(p) {}
private: CObject* m_native;
}

C # объект

class CSHObject : CLRObject {
}

Теперь, поскольку CSHObject отправляется в качестве аргумента события нескольким обработчикам, они все получают ссылку на один и тот же объект. Поэтому, когда один из обработчиков событий изменит объект, который передается событием, другие слушатели события получат измененный объект.

Например:

C ++ создает объект:

void updateListeners() {
updateListener(new CObject());
}

CLR перезаписывает updateListener:

void updateListener(CObject* obj) {
m_wrapper->updateListener(gcnew CLRObject(obj))
}

C # поднимет событие:

public event EventHandler<MyEventArgs> MyEvent;
void updateListener(CLRObject obj) {
MyEvent?.Invoke(this, new MyEventArgs(new CSHObject(obj)));
}

Теперь мой вопрос, как мы должны обрабатывать эти события? с точки зрения MVVM. Потому что CLRObject является моделью в этом случае, но одна модель совместно используется несколькими моделями представления. Который я думаю не правильный путь MVVM.

Так:

  1. Должны ли все слушатели событий создавать свои собственные Модели и копировать необходимую информацию из CLRObject?

  2. каждый слушатель события создает глубокую копию объекта?

  3. текущая реализация — правильный путь, и я не должен измениться.

обсерватория:

  1. У меня нет хороших знаний в C #, CLR.
  2. Весь пример кода составлен, потому что реальный код слишком длинный и содержит много других вещей.

2

Решение

Задача ещё не решена.

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]