Посредник сообщения графика модели C # MVVM или INotifyPropertyChanged? - PullRequest
1 голос
/ 28 октября 2019

Я занимаюсь разработкой приложения C # MVVM WPF, и у меня возникают проблемы, чтобы решить, следует ли мне использовать шаблон посредника сообщений или простой INotifyPropertyChanged для моего "живого" уведомления о смене модели пользовательского интерфейса. В частности, проблема заключается в том, что моя модель представляет собой граф с большим количеством «живых» объектов, у всех из которых есть свойства, и в какой-то момент различные видовые модели будут заинтересованы в изменениях. У меня есть около 3-5 активных моделей, которые нуждаются в уведомлении об изменениях модели. Некоторые изменения могут быть вложены глубоко в модели «внуков».

Я попытался сравнить оба метода обмена сообщениями, шаблон посредника и INotifyPropertyChanged, и думаю, что посредник лучше подходит для уведомлений об изменениях между различными модулями / системами. Моим моделям представления определенно нужны начальные значения модели после инициализации, а затем изменения уведомлений. INotifyPropertyChanged, кажется, является оптимальным выбором в моем случае, но я немного скептически настроен, потому что я думаю, что многие варианты переключателей nameof (e.PropertyName) не очень элегантны. Есть ли лучшие альтернативы для этой проблемы?

1 Ответ

0 голосов
/ 28 октября 2019

Как типично для таких случаев, вы можете использовать оба способа. Очевидно, вы не сможете избежать использования INotifyPropertyChanged, потому что это способ WPF для обработки привязки данных на основе MVVM, поэтому все ваши модели представлений будут, по крайней мере, базовыми реализациями этого интерфейса.

Я подозреваю,что вам может просто понадобиться оба. Я бы не советовал использовать шаблон на основе INotifyPropertyChanged внутри вашей модели. Причина, по которой этот интерфейс был создан, заключалась в том, что шаблон наблюдателя основывался на реальных именах свойств как strings . Это была в значительной степени «улица с односторонним движением», поскольку XAML, типичный язык «проектирования», поддерживающий WPF, анализируется «строго» * ​​1009 *, оставляя мало эффективных альтернатив. По моему скромному мнению, почти нет причин, по которым вы бы хотели, чтобы уведомления по всей вашей модели были такими же слабо типизированными (по сути, строковыми), как этот сценарий, поэтому я бы предложил избегать INotifyPropertyChanged, если у вас естьотносительно объемная модель предметной области.

Обмен сообщениями, вероятно, был бы подходящим способом, поддерживая строгую типизацию с регистрациями типов сообщений и так далее, если вы не хотите рассматривать другие альтернативы, такие как простые события C #, или даже комбинировать оба,При этом старайтесь придерживаться иерархии и инкапсуляции настолько сильно, насколько это возможно, но также и настолько слабо, насколько это практически возможно. *.

(* Я имею в виду, если некоторые из ваших объектов Домена достигают нескольких уровней вложенности, иногда, может быть более практичным обходить иерархию и позволить, например, правнукам отправлять собственные сообщения вместо того, чтобы уведомлять родителей своих родителей о событиях, и разрешать родителям этих родителей , а затем отправлять соответствующиеуведомления. В типичном программировании ООП компромиссы постоянно взвешиваются с учетом практичности и доступности времени.

...