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

Question

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

В сочетании с /questions/2227796/realizatsiya-inotifypropertychanged-suschestvuet-li-luchshij-sposob/2227824#2227824 это даже не должно быть очень безобразным.

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

Answer 1

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

Причины этого:

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

Answer 2

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

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

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

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

Answer 3

Чтобы не вставлять код в ваши классы, вы можете создать прозрачный прокси. Вы можете использовать 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