Что-нибудь говорит против того, чтобы все объекты домена наследовались от INotifyPropertyChanged?

Я занимаюсь рефакторингом и редизайном объектов домена своего приложения, которое в некоторой степени использует MVVM. Есть ли что-нибудь, что говорит против того, чтобы все объекты домена (POCO) наследуются от INotifyPropertyChanged, чтобы любой мог наблюдать за объектами как они хотят.

В сочетании с https://stackoverflow.com/a/1316566/448357 это даже не должно быть очень уродливым.

С другой стороны, как насчет загрязнения моего доменного объекта вещами, которые могут вообще не потребоваться, потому что будет отдельная View-Model в любом случае? Маргабит отмечает: Модель пользовательского интерфейса != Модель предметной области


mvvm architecture c# inotifypropertychanged domain-object
person Alexander Pacha    schedule 10.07.2014    source источник
comment
Вы знаете, что загрязняет окружающую среду? Наличие моделей домена/интерфейса, с которых вам постоянно приходится переключаться. Я видел это, и это некрасиво. Нет ничего плохого в том, чтобы создать базовый класс, реализующий INPC и все остальное, что удобно для ваших моделей. Ваш пупок, он не требует, чтобы вы смотрели на него так долго. Двигаться дальше.   -  person    schedule 10.07.2014

Ответы (3)


arrow_upward
1
arrow_downward

ИМО, объекты домена не должны реализовывать INotifyPropertyChanged. Тот, кто должен реализовать это, — это ваша ViewModel.

Причины тому:

  1. Вам, вероятно, в основном нужно будет вызвать событие PropertyChanged внутри вашей модели просмотра, которая содержит ваши POCO.
  2. Вы будете реализовывать его только один раз.
  3. Если ваш POCO хочет вызвать событие и уведомить о том, что внутри него что-то произошло, я не уверен, что PropertyChanged будет наиболее значимым событием для возбуждения.
person Yuval Itzchakov    schedule 10.07.2014

arrow_upward
1
arrow_downward

Я думаю, что это немного зависит от масштаба проекта: если это небольшой проект, где доменные модели также используются в качестве UI-моделей, обязательно сделайте это, если хотите.

Но если вам часто НУЖНЫ UI-модели, например. поскольку есть много свойств/методов, которые не являются частью вашей предметной модели, не беспокойтесь - вы создаете накладные расходы по незначительной причине или без таковой.

Когда вам нужна UI-модель? Мое практическое правило: если вы представляете свойство с атрибутом [NotMapped] (Entity Framework), продолжайте и создайте UI-модель с этим свойством.

Кроме того, если есть вероятность, что части этого проекта используются в другом контексте (веб-приложение, телефон и т. д.), я бы не советовал этого делать — вам все равно понадобятся модели пользовательского интерфейса.

person Christian Sauer    schedule 10.07.2014

arrow_upward
0
arrow_downward

Чтобы не вставлять код в свои классы, вы можете сделать прозрачный прокси. Вы можете использовать Castle http://www.castleproject.org/dynamicproxy/index.html.

Единственное ограничение заключается в том, что вы должны создавать экземпляры своих классов через фабрику.

Вы также можете использовать класс System.Runtime.Remoting.Proxies.RealProxy, но ваш базовый класс должен быть производным от MarshalByRef (все еще POCO? :)).

http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=IT-IT&k=k%28SYSTEM.RUNTIME.REMOTING.PROXIES.REALPROXY%29%3bk%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22%29%3bk%28DevLang-CSHARP%29&rd=true

person bubi    schedule 10.07.2014