Я тут не очень понял суть проблемы. В моём понимании Вы создаете элемент управления DateRangeSelector, наследуясь от UserControl, в нём создаёте 2 DependencyProperty StartDate, EndDate. В Xaml кладёте 2 DatePicker и связываете их с этими свойствами. Во всех местах, где Вам нужно выбирать интервал из дат Вы кладёте этот элемент управления и связываете его свойства StartDate и EndDate со свойствами VM.
Никто не заставляет Вас биндиться к Dependency свойствам. Можно и в UserControl создавать обычные CLR свойства и реализовывать INotifyPropertyChanged (хотя это было бы странно, учитывая что наследуемся от DependencyObject). Вы не подумайте, что я придраться хочу и доказать, что MVVM плохо. Я задаю Вам простые вопросы с целью понять, для чего мне MVVM, почему я не могу считать Codebehind UserControl'а VM'ом. Название Вашей статьи предполагает, что Вы в полной мере объясните цель и причины использования MVVM в WPF. Вот я и хочу укрепить свои знания и получить еще одно видение.
Да, вопрос именно в чем преимущество. MVVM позволяет нам писать код в декларативном виде (Xaml), используя событийную модель. Т.е. INotifyPropertyChanged, Binding, Multibinding, ICommand, Trigger и вся прочая ерунда, поддерживаемая самой платформой напрямую. Когда на собеседовании я спрашиваю у кандидата для чего MVVM, мне бы хотелось услышать объяснение, увидеть понимание сущности самого шаблона, способности объяснить его отличие от MVC, к примеру, а не просто потому что нам так сказали. Какой смысл пользоваться чем-то, когда не понимаешь смысла, не видишь отличий от других подходов. Рассказывая кому-либо о шаблоне проектирования, я бы начинал от классификации (структурный, поведенческий, порождающий), дальше цель шаблона и пример решаемых с его помощью задач, причина, по которой следует использовать тот или иной подход. Голословного «в WPF так принято» не достаточно.
В любом приложении есть модель и её представление. Шаблонов проектирования, в которых модель связывается с представлением много: MVC, MVP, MVVM. То, что модель должна быть отделена от инфраструктурного кода — это как раз понятно. Вопрос больше про то, для чего использовать сам шаблон MVVM. Что его использование даёт по сравнению с тем, что я напишу контроллер, через который вид взаимодействует с моделью. Или я буду просто в Codebehind взаимодействовать с моделью. Вопрос не о M, а о VM из этого шаблона. Я на самом деле знаю ответ на этот вопрос. Просто, читая статью о шаблоне проектирования, хотел бы видеть в ней объяснение. Возможно новички прочитают и не поймут для чего всё это нужно.
Самому UserControl'у необязательно устанавливать DataContext'ом ссылку на себя, для того, чтобы использовать привязки внутри. Можно, например, задать имя контролу и в привязках ссылаться на контрол по этому имени:
Использовать один контрол в качестве DataContext другого нелогично, я с Вами согласен. Вот Вы пишете, что часто бывает одна большая VM которая используется для многих View, но городить один большой View не хотите. А почему тогда получается 1 большая VM, котороая во многих View участвует? Почему её не нужно разбивать на более мелкие части, как это делаете с View? Или это что-то вроде медиатора, который устанавливает связь между различными частями модели в 1-м месте, но используется во многих местах? Т.е. другими словами мне пока не понятен смысл выносить код взаимодействия с моделью в отдельный класс, когда есть Codebehind у UserControl. В Вашем примере получается, что Codebehind во всех представлениях чаще всего останется пустым.
В моём понимании любой шаблон проектирования предназначен для решения определённой категории задач. Часто, читая статью про какой-либо шаблон проектирования, я вижу пример реализации этого шаблона для решения какой-то элементарнейшей задачи. При этом я вижу кучу непонятных абстракций и усложнений кода, реализация которых, зачастую, сложнее решения этой самой элементарнейшей задачи. Мне говорят, как надо делать, как нельзя делать, но не объясняют зачем вообще все это делать. Вот статья — классический пример. Аргументация такая: посмотрите на серверную стойку с лапшой из проводов, и посмотрите на другую стойку, где красота и порядок. Так вот пример с серверной стойкой мне, очевидно, понятен. И у меня не возникает вопросов, зачем использовать хомутики и жгутики. Ну а далее что? Давайте напишем даже не калькулятор, а просто сумматор 2-х чисел и будем MVVM-ить. Из статьи я понял как нужно соединять порты, но не понял для чего мне MVVM. Так что, если Вы беретесь объяснять за шаблоны проектирования, приведите пример, на котором применение этого самого шаблона будет аргументировано и будет видна его польза. Ну да ладно, всё-таки это часть 1, возможно, дальше будет больше и понятней.
Теперь вопрос по существу (возможно на вопрос «зачем» из 1-й части моего комментария Вы ответите здесь). Предположим есть UserControl, он состоит из 2-х частей View (Xaml) и Codebehind (cs). Во View значит я верстаю саму форму, кладу TextBox. В Codebehind я создаю такие же команды и свойства, как это делаете Вы в своей ViewModel, и во View точно также создаю привязки к этим свойствам и командам. Т.е. Codebehind UserControl'а это Ваш ViewModel. Так для чего же мне уже имея View и Codebehind создавать ещё один файл и выносить туда какой-либо код?
Согласен с Вами, считаю, что алгоритмы все-таки нужно знать. Пускай не по памяти писать RB-tree, но понимать, что такое двоичное дерево поиска или как работает сортировка все-таки нужно. И структуры данных тоже знать. Но сегодня такая тенденция, что приходят на собеседование хипстеры, которые знают, как подключить пакет для определения типа объекта, настроить bower gulp и т.д. А потом глаза слезятся кровами слезами, когда в коде вместо двумерного массива я встречаю словарь словарей типа Dictionary<int, Dictionary<int, MyObject>>, в которых ключи словарей – это индексы по строке столбцу. И да, здесь речь не о разреженных структурах данных, а самый обычный двумерный массив. И таких примеров ужасов еще вагон с маленькой тележкой. А все почему, хипстер ведь не знает, что такое двоичное дерево поиска или хеш-таблица. Главное, что есть некий контейнер, у которого можно забирать значение по индексу. Я, когда собеседования проводил (хоть я и признаю, что особо не умею этого делать), на вопрос, что такое связанный список из кандидатов 20 услышал ответ может только у 1, и то с подсказками. Больше половины не понимали вопрос «какие структуры данных вам известны, о каких можете рассказать, какие использовали». Соискатели делают круглые глаза и переспрашивают: «это типа Point, Rectangle?». Хотя если так подумать, чтобы клепать примитивные формочки с 20 input’ами, и генерировать таблицы в БД может и не нужно понимать описанных вещей, а нужно обладать совсем другими навыками.
Это все, конечно, здорово на этапе проектирования нового приложения. Тогда можно выбрать operation-oriented или value-oriented метод, и в соответствии с этим реализовывать логику приложения. Но когда вашему приложению уже 5 лет, у вас куча всевозможных действий над данными, и вдруг менеджер проекта решает, что пора бы вам прикрутить Undo/Redo, то тот самый плохой 3-й способ может быть единственным решением, без переписывания всего приложения.
Методы 1, 2 и 3 генерируют одинаковый IL код, разница лишь в предпочтении автора. 1-й может привести к ошибке, в случае переименования свойства,. 2-й метод в этом плане удобнее, т.к. инструмент вроде ReSharper автоматически переименует и свойство, и конструкцию nameof(Property). 5-й метод может быть удобен для реализации дополнительной логики: логирование, сравнение значений и генерация события лишь на действительном изменении значения, генерация события PropertyChanging а потом PropertyChanged. 4,6,7 не вижу смысла, да и вообще велосипеды облегчения реализации INotifyPropertyChanged не читаю, будто других проблем в WPF нет, как сэкономить 1 строку кода на 1-м свойстве. «Дабпиэф ничего не поделаешь» при отрисовке списка говорят, наверное, только джуны, никогда не читавшие исходников VirtualizingStackPanel и ItemsControl и не писавших свои панели, реализующие виртуализацию отображения, там в принципе нечему тормозить.
55% денег уйдет сайту, 15% пользователю браузера и каких-то 30% изобретателям этой чудной схемы монетизации. А если пользователь не захочет смотреть рекламу, то будет платить подписку создателям. Я прямо уже мечтаю поскорее заменить мою бесплатную Оперу + ABP.
В любом приложении есть модель и её представление. Шаблонов проектирования, в которых модель связывается с представлением много: MVC, MVP, MVVM. То, что модель должна быть отделена от инфраструктурного кода — это как раз понятно. Вопрос больше про то, для чего использовать сам шаблон MVVM. Что его использование даёт по сравнению с тем, что я напишу контроллер, через который вид взаимодействует с моделью. Или я буду просто в Codebehind взаимодействовать с моделью. Вопрос не о M, а о VM из этого шаблона. Я на самом деле знаю ответ на этот вопрос. Просто, читая статью о шаблоне проектирования, хотел бы видеть в ней объяснение. Возможно новички прочитают и не поймут для чего всё это нужно.
Использовать один контрол в качестве DataContext другого нелогично, я с Вами согласен. Вот Вы пишете, что часто бывает одна большая VM которая используется для многих View, но городить один большой View не хотите. А почему тогда получается 1 большая VM, котороая во многих View участвует? Почему её не нужно разбивать на более мелкие части, как это делаете с View? Или это что-то вроде медиатора, который устанавливает связь между различными частями модели в 1-м месте, но используется во многих местах? Т.е. другими словами мне пока не понятен смысл выносить код взаимодействия с моделью в отдельный класс, когда есть Codebehind у UserControl. В Вашем примере получается, что Codebehind во всех представлениях чаще всего останется пустым.
Теперь вопрос по существу (возможно на вопрос «зачем» из 1-й части моего комментария Вы ответите здесь). Предположим есть UserControl, он состоит из 2-х частей View (Xaml) и Codebehind (cs). Во View значит я верстаю саму форму, кладу TextBox. В Codebehind я создаю такие же команды и свойства, как это делаете Вы в своей ViewModel, и во View точно также создаю привязки к этим свойствам и командам. Т.е. Codebehind UserControl'а это Ваш ViewModel. Так для чего же мне уже имея View и Codebehind создавать ещё один файл и выносить туда какой-либо код?