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