Приложение MVVM. Диалог добавления/редактирования товара: получение данных, вызов, взаимодействие с VM и прочее

В этой теме обсуждается только вопросы по реализации Диалога редактирования товара и связанных с этим действиях . Основная тема: Приложение MVVM. VMs и навигация

Сообщение от Элд Хасп Я изначально предлагал другой вариант, гораздо проще реализуемый:

Просто в одном варианте задания были требования по реализации редактирования с помощью контекстного меню. Вот поэтому я и заинтересовался. К тому же хотелось получить какой-то опыт работы с ним

Добавлено через 3 минуты
Меня интересует маппер. Он инициализирует свойства составного типа такие как Manufacturer?

0

Сообщение от Элд Хасп Не так всё просто, но попробуйте.

А, ну да, значение введется и в случае с Binding.DoNothing оно просто в источнике не поменяется, останется старым, так?

Добавлено через 1 минуту
А в таком случае будет вызвано перечитывание значения из get? Мне кажется нет

0

INexteR, изменил цифровые конвертеры на общий.
И вынес валидацию из сеттеров.
Посмотрите фиксацию.

Добавлено через 1 минуту

Сообщение от INexteR А в таком случае будет вызвано перечитывание значения из get? Мне кажется нет

Не будет.
Перечитывание возникает после присвоения значения свойства.

1

INexteR, я ещё подправил контекстное меню.

1

Сообщение от Элд Хасп я ещё подправил контекстное меню.

Почему вас не устраивает просто при загрузке в обработчике произвести настройку один раз?

0

Сообщение от INexteR Почему вас не устраивает просто при загрузке в обработчике произвести настройку один раз?

Потому что это загрузка Окна.
Окно не должно отвечать по функционалу за такие вещи.
В данном случае у вас всё сделано "в одной каше", но "по взрослому" Окно разбивается на Регионы.
В данном случае, будет выделен регион Списка и в неё Регионы элементов Списка.
Контекстное меню - это часть региона элемента списка.
Окно ничего не знает о регионе третьего уровня вложенности и не сможет там ничего настраивать.

Добавлено через 1 минуту
В текущей разметке перенесите Контекстное Меню в ресурсы Шаблона Элемента Товара и попробуйте его настроить.

0

Элд Хасп, Отправка объекта IList с выбранными элементами в ViewModel почему тогда Вы тут ничего против не сказали? Тоже используется обработчик события Loaded

0

Сообщение от INexteR почему тогда Вы тут ничего против не сказали?

Он же сам написал:

Сообщение от Andrey-MSK ... когда лень писать кучу свойств в VM, потом их привязывать ...

Что здесь написать? "Не надо лениться!"?

0

Элд Хасп, понятно. Но только в моем случае я не поленился, а попытался избежать ненужной работы, или, как Вы говорите, сэкономил доллар

0

Элд Хасп, а Вы же не объединили обработчик PreviewTextInput с конвертером?

0

Сообщение от INexteR а Вы же не объединили обработчик PreviewTextInput с конвертером?

Нет.
Мне не приходи в голову как это сделать, чтобы упростить, а не усложнить.
Упростить XAML можно но Шарп резко осложнится.
Проблема в том, что Binding защищён от изменений и от него нельзя сделать производный класс...

Вернее, защищён не он, а его метод ProvideValue и нельзя его переопределить.
А информацию об элементе, который использует Binding можно получить только из этого метода.
Поэтому придётся делать фактически свой кастомный Binding "с нуля". А это ОЧЕНЬ сложно.

0

Сообщение от Элд Хасп Поэтому придётся делать фактически свой кастомный Binding "с нуля". А это ОЧЕНЬ сложно.

Ну это вообще не вариант, даже не думайте о таком

0

Сообщение от INexteR Ну это вообще не вариант, даже не думайте о таком

У меня есть библиотечный элемент: Непростое Решение для простой часто встречающейся задачи. Привязка TextBox к численному свойству [WPF, Элд Хасп]

0

Элд Хасп, в этой реализации осталась такая засечка, что на форме авторизации в текстовом блоке статус отображается как значение из перечисления. Тут нужен DictionaryConverter, верно?

Добавлено через 1 минуту
И вот я думаю, что хотел бы в следующей реализации испробовать подход с использованием DTO вместо интерфейсов. А также при редактировании я бы не хотел менять сущности целиком, а только свойства

Добавлено через 8 минут
Мне нужно создать новый проект. И он будет на порядок сложнее, чем тот, что мы делали на демоэкзамен. Сможете помочь с ним? Предметной областью будет являться санаторий. Там уже нужно будет добавлять и редактировать: клиентов, заказы, процедуры и проч. Первой проблемой для меня является создание правильной бд

Добавлено через 1 минуту
Элд Хасп, первоначально мой путь лежит через раздел баз данных и ADO, верно?

0

Сообщение от INexteR в этой реализации осталась такая засечка, что на форме авторизации в текстовом блоке статус отображается как значение из перечисления. Тут нужен DictionaryConverter, верно?

Или триггерами, или конвертерами. DictionaryConverter - это один из вариантов конвертера, чтобы делать новый "на каждый чих".

Сообщение от INexteR И вот я думаю, что хотел бы в следующей реализации испробовать подход с использованием DTO вместо интерфейсов.

Допустимо.

Сообщение от INexteR А также при редактировании я бы не хотел менять сущности целиком, а только свойства

Как?
VM отражает Модель, а не View.
Модель делает ПОПЫТКУ изменения в ХРАНИЛИЩЕ.
Если попытка удачна, то нужно уведомить своих потребителей об изменении.
Если уведомлять о замене сущности, то мы получаем новую сущность и целиком её отправляем потребителям.

А если уведомлять только об изменении одного из свойств, то придётся отправлять событие НА КАЖДОЕ изменённое свойство.
Это сложнее, объёмнее по коду как в Модели так и в её потребителях.
Я даже не знаю в каких сценариях это может быть эффективно.

Разве что огромные сущности, у которых одновременно может меняться одно-два свойства.
"Огромные" - это те которые в памяти занимают, наверное, сотни килобайт.

0

Сообщение от Элд Хасп А если уведомлять только об изменении одного из свойств, то придётся отправлять событие НА КАЖДОЕ изменённое свойство.

Просто сделать модель как таковую, которая реализует INPC

0

Сообщение от INexteR Первой проблемой для меня является создание правильной бд

Архитектура БД важна. НО, мы же работаем с Моделью. В данном случае БЛ, кроме работы с Хранилищем, пости ничего не будет содержать. Поэтому архитектура данных Модели и архитектура БД (Хранилища) будут совпадать.
Но это частный случай.
В общем случае нужно создавать эффективную архитектуру Модели, а как ей удобно сохранять - это вторичный вопрос.

Сообщение от INexteR первоначально мой путь лежит через раздел баз данных и ADO, верно?

Особенно если это многопользовательское приложение.
У вас какая задача стоит?

Добавлено через 4 минуты

Сообщение от INexteR Просто сделать модель как таковую, которая реализует INPC

Не Модель, а сущность вы, наверное, имеете ввиду.

И посмотрите что вы получите.
ПЕРЕД обновлением БД, вы сначала изменяете сущность. И все изменения отразятся в View. Если сохранения не произойдёт, View, то разорвётся связь. В Хранилище будут одни данные, в Модели другие.

Если сохранять, и потом обновлять сущность, то придётся это делать отдельно для каждого свойства.
И что этим выиграется?
Только код станет объёмнее и запутанее.

Добавлено через 48 секунд
Если уже есть сохранённая сущность, зачем из неё данные переписывать в старую, если гораздо проще заменить их?

0

Сообщение от Элд Хасп Особенно если это многопользовательское приложение.

К счастью нет. Задача - проект на диплом. Там то же, что и на демоэкзамен, только несколько сущностей нужно охватить для работы с ними. И ещё нужно выводить некоторые данные в отчет - word/excel

Сообщение от Элд Хасп Не Модель, а сущность вы, наверное, имеете ввиду.

А вот и нет, модель. Например, возьмем то же свойство AuthorizationStatus. Мы не станем выделять событие StatusChanged, а просто заменим его на PropertyChanged и в сеттере свойства будем производить вызов. Далее VM подпишется на это событие и дальше пробросит к view

Добавлено через 9 минут

Сообщение от Элд Хасп ПЕРЕД обновлением БД, вы сначала изменяете сущность. И все изменения отразятся в View. Если сохранения не произойдёт, View, то разорвётся связь. В Хранилище будут одни данные, в Модели другие.

Согласен, действительно ситуация тупиковая. Ну, видимо, тогда рассматривать данный вариант не стоит. Остается только замена интерфейсов на DTO

0

Если уже есть сохранённая сущность, зачем из неё данные переписывать в старую, если гораздо проще заменить их?

Сообщение от INexteR , только несколько сущностей нужно охватить для работы с ними.

С несколькими изменяемыми сущностями сразу возникнет проблема уведомления об изменений сущности навигационного свойства.
Один из вариантов я вам показывал в теме Отправка объекта IList с выбранными элементами в ViewModel

Сообщение от INexteR А вот и нет, модель. Например, возьмем то же свойство AuthorizationStatus. Мы не станем выделять событие StatusChanged, а просто заменим его на PropertyChanged

Можно.
У меня даже тема есть соответствующая INPC (INotifyPropertyChanged) и получение данных из Модели [WPF, Элд Хасп]
Но "поигравшись" с множеством различных реализаций, всё же приходишь к мнению, что INPC неудобен.
По сути он имеет преимущества только, если работа данными идёт с использованием рефлексии или чего-то близкого (привязки, например). Или когда очень много свойств и за всеми нужно следить по отдельности.
В Шарпе же принята всё таки строгая типизация и с ней лучше сочетаются индивидуальные события.
Например, при изменении статуса у нас же меняется не только Статус, но и текущий пользователь.
А ДЛЯ INPC нужно делать их раздельную прослушку.

1

Элд Хасп, то есть по вашему мнению существует только одна адекватная реализация редактирования - замена сущности целиком. Или есть ещё какие-то варианты?

И сейчас у меня ещё два вопроса возникло.

В одном из вариантов того же демо экзамена есть условие: если у товара имеется скидка, то основная цена должна быть перечеркнута и рядом дописана цена с учетом скидки. Здесь, я так понимаю, для перечеркивания нужно воспользоваться свойством TextBlock.TextDecorations. И раз тут нужно два текста, где один перечеркнут, другой нормальный, то потребуется 2 объекта Run. Проблема: нужно переменное число объектов в зависимости от условия. Хотел создать конвертер, который будет формировать эти объекты, но вот незадача: свойство TextBlock.Inlines не имеет метода задания и к тому же оно не DP. Как тут быть?

Второй вопрос. Вот, скажем, для тех же товаров задаю DataTemplate в ListBox. И весь этот шаблон создаю в элементе, производном от UserControl. Ну вот так мне захотелось писать, не прямо в DataTemplate, а в отдельном файле. И вопрос: почему я в моем шаблоне DataTemplate в DataTrigger не могу обратиться к именованному элементу, который находится в UserControl? Пример (содержимое UserControl):
И ListBox:
А вот так все в порядке, если не выносить разметку в отдельный UserControl:
Добавлено через 7 минут
По поводу второго вопроса я сейчас подумал: причина в области видимости? Область видимости именованного StackPanel в UserControl отлична от той, когда он создается в шаблоне. То есть в шаблоне рассматриваются только те элементы, которые были созданы и именованы непосредственно в нем

0

Сообщение от INexteR о есть по вашему мнению существует только одна адекватная реализация редактирования - замена сущности целиком. Или есть ещё какие-то варианты?

В данном случае, на мой взгляд, любой другой вариант будет менее оптимальным.
Но опять таки, не исключаю, что какой-то вариант мне просто не пришёл в голову.

Но есть же ещё и другие задачи.
Например, изменения могут накапливаться в Модели, и их сохранение происходит явным вызовом метода.
В таком случае, данные Модели уже не отражают Хранилище и здесь замена сущностей это не единственный вариант.

Например, игра. Есть предметы, поля, юниты и т.д. Всё это взаимодействует между собой. И если уменьшилось здоровье юнита, то можно только об этом и уведомить через INPC.

Добавлено через 3 минуты

Сообщение от INexteR й, то потребуется 2 объекта Run. Проблема: нужно переменное число объектов в зависимости от условия.

Как я понимаю.
Есть текущая цена, которая отображается всегда.
В некоторых случаях есть предыдущая цена. Так как она есть не у всех товаров, то это должен быть Nullable<decimal>.

Что касается вывода, то можно сделать два TextBlock. Тот который выводит Nullable коллапсирует, если null.

Добавлено через 4 минуты

Сообщение от INexteR причина в области видимости?

Всё верно.
Целевой элемент вычисляет ДО применения шаблона. И в это время он никак не может увидеть элементы вне себя.

0