Даже если кто-то случайно сломает сеарилизованный файл, то пользователю просто-напросто вернётся дефолтная вью-модель в том состоянии, которое было при первом запуске.
Причём, если немного развить этот подход, то можно сделать что-то вроде различных вью-модов. То есть, например, полное представление информации, сокращённое, совсем краткое или даже кастомное. Другими словами — это сохранение настроек (состояний) интерфейса с возможностью выбора.
А картинки вы храните в каком виде? UI — это своего рода не картинка?..
И какие трудности с редактированием сериализованного XML или Json-файла?
Их можно хоть вручную редактировать или сделать простенькую утилиту, в чём сложность?
Почему вы не хотите хранить сериализованный файл в БД?
Неужели это кажется таким избыточным? По-моему, очевидно, просто и очень удобно…
Конечно, может быть, у приложения миллионы пользователей, но это уже совсем другая история…
— в качестве представления (View) можно использовать любой контрол, поэтому порой не обязательно выделять представление в отдельную сущность (новый класс), а также добавлять свойство в другую вью-модель. Поясню на примере:
То есть нам не нужно инжектировать DetailsViewModel в MainViewModel, только ради того, чтобы где-то на интерфейсе отобразить свойство Name, также не нужно, например, создавать DetailsShortView. В проекте получается меньше классов, а структура остаётся понятной.
— в статье я показал основные принципы, используя которые можно быстро и качественно сделать функциональное приложение. Совершенно не обязательно использовать всё как есть, вы в праве совершенствовать, видоизменять и фантазировать! В этом и есть развитие, успехов вам! :)
Всё, что нужно, — это делать сериализацию не в файл, а передавать сериализованный объект на сервер.
Конечно, придётся сделать логику администрирования и взаимодействия с сервером, но в этом тоже ничего сложного не вижу.
В статье я просто рассказал про основные идеи, которые родились при разработке реального проекта с нуля.
Подход гибкий, поэтому если кто-то считает, что реализовано что-то не по феншую, то всегда можно допилить под свои нужды.
Возможно, я не очень ясно выразился… Вью модели содержат у меня всю промежуточную логику между интерфейсом и бизнес-правилами, например, валидацию или логику выполнения команд. Понятно, что какие-то специфические операции для работы с моделями иногда лучше вынести в отдельные классы, например, поиск по записям.
Вы не совсем поняли.
Если рассмотреть пример, то базовые классы — это ViewModelBase и ViewModel, а конкретная реализация MainViewModel. Базовые классы не есть представление (представление — это просто xaml-разметка), скорее они больше похожи на презентатор.
Боюсь, ваше предложение насчёт Model совсем не уместно…
Моя цель не жёсткое следование методологии, а удобство разработки, лаконичность и чистота кода. На реальном проекте (Poet) подход показал себя очень хорошо, и я решил поделиться им с другими людьми. Использовать его или нет, решать вам самим. Согласен, что с первого взгляда он может показаться немного диковатым, но лишь применив его на практике можно почувствовать всю его прелесть, гибкость и мощь.
От инжекций в конструктор отказываться не обязательно, но, на мой взгляд, в этом есть определённые плюсы. Мне всегда казалось избыточным, что в тестах в конструкторах часто проверяются параметры на null и больше ничего интересного не происходит. Если вдруг контейнер вернёт null, то заметишь и исправишь в любом месте кода (для этого, собственно, тесты и нужны), а зачем переносить такие проверки в конструктор не совсем понятно.
Конечно, я знаю, что DataMember это про DTO, но в этом-то и некоторая новизна идеи, что мы будем сериализовать вью-модели…
Здесь есть разделение ответственности — базовые класы инкапсулируют интерфейсную логику, а конкретные реализации бизнес-логику.
Костылём я бы не назвал, всё это позволило создать полноценное и функциональное приложение, а «тот самый момент», так и не наступил.
Мне тут предложили новое название для паттерна — MVVMP :)
(mvvm+mvp)=mv(vm+p)
Похоже на уравнение из физики.
Не знаю, эволюционный или революционный это подход, но, думаю, имеет право на жизнь :)
По крайней мере, для небольших утилит подходит как нельзя лучше. Хотя есть подозрения, что и в крупных проектах может пригодиться…
Возможно, dynamic тоже можно прикрутить к данной схеме, но у меня большие опасения насчёт производительности.
С индексатором всё очень удобно и быстро работает.
К тому же, если вдруг, гипотетически, какое-то неявное свойство меняется, ну, с очень большой частотой и сопровождается большими вычислениями, то можно вынести его в обычное явное, и всё тут :)
CallerMemberName тоже вариант, но лябда-выражения всё же более гибкие. Думаю, дело вкуса.
Вам решать) Об абстрактных сущностях спорить можно целую вечность… Создайте конкретное приложение со множеством представлений, богатым интерфейсом и сохранением их визуального состояния, а затем просто сравните объёмы и чистоту написанного кода. Если получится лучше, то мы лишь вместе порадуемся этому факту, а пока так :)
Я не очень силён в специфике веб-разработки, но несколько основных идей статьи назову:
— перенос свойств интерфейсной логики во вью модель, минимум CodeBehind;
— задание «чисто» интерфейсных свойств неявным образом и сокращение объёмов кода;
— отказ от инжекций в конструктор;
— усовершенствование механизма RoutedCommands и CommandBindings;
— добаление механизма PropertyBindings в дополнение к обычным Binding;
— интенсивное использование лямбда-выражений;
— стремление к простоте, удобству и красоте кода!
Да, опечатка будет восприниматься как новое неявное свойство :)
Но в этом нет большой проблемы, всё сразу будет заметно на юае, и запоминать особо ничего не нужно.
Это очень резонный вопрос, я и сам думал над этим…
Понятно, что о теории любой методологии можно спорить долго, но я в первую очередь руководствуюсь практической ценностью и удобством.
Для себя я решил, что View это просто интерфейс-картинка (разметка xaml) и в идеале он CodeBehind вовсе не содержит, Мodel, само собой, модель данных, а ViewModel — это то, как отображаются данные, а размер окна это и есть одно из свойств этого отображения. То есть вью-модель это смесь бизнес-логики и интерфейсной… И это нормально.
Но дело-то вот в чём, к примеру, на представлении есть несколько контролов, которые работают с одним свойством ShowDetails по двусторонней привязке (оно на данные никак не влияет, только на их отображение). Дата контекст у всех контролов общий — вью-модель, а сами в свою очередь они отображают бизнес-данные, поэтому дата-контекст просто не поменяешь. Не самое красивое решение создавать привязку по цепочке контролов, поэтому логичнее привязать из к чему-то общему — непосредственно к свойству ShowDetails. Где разместить это свойство? В CodeBehind и создавать умный юай (Smart UI) или поместить во вью-модель? Второе гораздо удобнее, на мой взгляд, да и методологию не нарушает. К тому же применение индексатора позволяет во многих случаях избежать создания свойства ShowDetails в классе как такового, оно лишь подразумевается в xaml…
Не знаю, понятно ли я описал идею, но по своему опыту скажу, что в проекте, который я разрабатываю, это сократило объём кода в разы, а вью-модели остались очень чистыми, и это не пустые слова. Думаю, чтобы ощутить всё это удобство и красоту — нужно просто попробовать.
В этом и есть отчасти некоторая революционность подхода — перенос ряда свойств интерфейса во вью модель.
P.S. Спасибо, что интересуетесь статьёй и обсуждаете её. Смело спрашивайте ещё, если я не совсем понятно объясняю )
Причём, если немного развить этот подход, то можно сделать что-то вроде различных вью-модов. То есть, например, полное представление информации, сокращённое, совсем краткое или даже кастомное. Другими словами — это сохранение настроек (состояний) интерфейса с возможностью выбора.
И какие трудности с редактированием сериализованного XML или Json-файла?
Их можно хоть вручную редактировать или сделать простенькую утилиту, в чём сложность?
Неужели это кажется таким избыточным? По-моему, очевидно, просто и очень удобно…
Конечно, может быть, у приложения миллионы пользователей, но это уже совсем другая история…
— в качестве представления (View) можно использовать любой контрол, поэтому порой не обязательно выделять представление в отдельную сущность (новый класс), а также добавлять свойство в другую вью-модель. Поясню на примере:
<Window DataContext={Store viewModels:MainViewModel}>
…
<TextBlock DataContext={Store viewModels:DetailsViewModel} Text={Binding Name}/>
…
То есть нам не нужно инжектировать DetailsViewModel в MainViewModel, только ради того, чтобы где-то на интерфейсе отобразить свойство Name, также не нужно, например, создавать DetailsShortView. В проекте получается меньше классов, а структура остаётся понятной.
— в статье я показал основные принципы, используя которые можно быстро и качественно сделать функциональное приложение. Совершенно не обязательно использовать всё как есть, вы в праве совершенствовать, видоизменять и фантазировать! В этом и есть развитие, успехов вам! :)
Всё, что нужно, — это делать сериализацию не в файл, а передавать сериализованный объект на сервер.
Конечно, придётся сделать логику администрирования и взаимодействия с сервером, но в этом тоже ничего сложного не вижу.
Может, я не так вас понял? Поправьте меня…
В статье я просто рассказал про основные идеи, которые родились при разработке реального проекта с нуля.
Подход гибкий, поэтому если кто-то считает, что реализовано что-то не по феншую, то всегда можно допилить под свои нужды.
Спасибо, что исправляете!
Если рассмотреть пример, то базовые классы — это ViewModelBase и ViewModel, а конкретная реализация MainViewModel. Базовые классы не есть представление (представление — это просто xaml-разметка), скорее они больше похожи на презентатор.
Боюсь, ваше предложение насчёт Model совсем не уместно…
Моя цель не жёсткое следование методологии, а удобство разработки, лаконичность и чистота кода. На реальном проекте (Poet) подход показал себя очень хорошо, и я решил поделиться им с другими людьми. Использовать его или нет, решать вам самим. Согласен, что с первого взгляда он может показаться немного диковатым, но лишь применив его на практике можно почувствовать всю его прелесть, гибкость и мощь.
Конечно, я знаю, что DataMember это про DTO, но в этом-то и некоторая новизна идеи, что мы будем сериализовать вью-модели…
Костылём я бы не назвал, всё это позволило создать полноценное и функциональное приложение, а «тот самый момент», так и не наступил.
Мне тут предложили новое название для паттерна — MVVMP :)
(mvvm+mvp)=mv(vm+p)
Похоже на уравнение из физики.
Не знаю, эволюционный или революционный это подход, но, думаю, имеет право на жизнь :)
По крайней мере, для небольших утилит подходит как нельзя лучше. Хотя есть подозрения, что и в крупных проектах может пригодиться…
С индексатором всё очень удобно и быстро работает.
К тому же, если вдруг, гипотетически, какое-то неявное свойство меняется, ну, с очень большой частотой и сопровождается большими вычислениями, то можно вынести его в обычное явное, и всё тут :)
CallerMemberName тоже вариант, но лябда-выражения всё же более гибкие. Думаю, дело вкуса.
— перенос свойств интерфейсной логики во вью модель, минимум CodeBehind;
— задание «чисто» интерфейсных свойств неявным образом и сокращение объёмов кода;
— отказ от инжекций в конструктор;
— усовершенствование механизма RoutedCommands и CommandBindings;
— добаление механизма PropertyBindings в дополнение к обычным Binding;
— интенсивное использование лямбда-выражений;
— стремление к простоте, удобству и красоте кода!
Но в этом нет большой проблемы, всё сразу будет заметно на юае, и запоминать особо ничего не нужно.
Понятно, что о теории любой методологии можно спорить долго, но я в первую очередь руководствуюсь практической ценностью и удобством.
Для себя я решил, что View это просто интерфейс-картинка (разметка xaml) и в идеале он CodeBehind вовсе не содержит, Мodel, само собой, модель данных, а ViewModel — это то, как отображаются данные, а размер окна это и есть одно из свойств этого отображения. То есть вью-модель это смесь бизнес-логики и интерфейсной… И это нормально.
Но дело-то вот в чём, к примеру, на представлении есть несколько контролов, которые работают с одним свойством ShowDetails по двусторонней привязке (оно на данные никак не влияет, только на их отображение). Дата контекст у всех контролов общий — вью-модель, а сами в свою очередь они отображают бизнес-данные, поэтому дата-контекст просто не поменяешь. Не самое красивое решение создавать привязку по цепочке контролов, поэтому логичнее привязать из к чему-то общему — непосредственно к свойству ShowDetails. Где разместить это свойство? В CodeBehind и создавать умный юай (Smart UI) или поместить во вью-модель? Второе гораздо удобнее, на мой взгляд, да и методологию не нарушает. К тому же применение индексатора позволяет во многих случаях избежать создания свойства ShowDetails в классе как такового, оно лишь подразумевается в xaml…
Не знаю, понятно ли я описал идею, но по своему опыту скажу, что в проекте, который я разрабатываю, это сократило объём кода в разы, а вью-модели остались очень чистыми, и это не пустые слова. Думаю, чтобы ощутить всё это удобство и красоту — нужно просто попробовать.
В этом и есть отчасти некоторая революционность подхода — перенос ряда свойств интерфейса во вью модель.
P.S. Спасибо, что интересуетесь статьёй и обсуждаете её. Смело спрашивайте ещё, если я не совсем понятно объясняю )