кнопки и текст с количеством. Вопрос, как это лучше всего реализовать на WPF? У меня в идеях только давать название каждой кнопке, отслеживать нажатие на кнопки, проверять название и через switch перебирать названия и прибавлять (отнимать) нужный текстбокс. Может быть, есть другие, более удобные способы решения?
Генерируешь кнопки и текст на основе массива, подписываешь метод на ивенты этих кнопок
Создаёшь отдельный UserControl и ViewModel для него (Назовём ActorViewModel). ViewModel будет хранить в себе название, количество и 2 команды (увеличить и уменьшить количество). ViewModel, которая будет отображать всё это будет содержать в себе observable Collection в которой будут хранится ActorViewModel разные. На View будет обычный ItemsControl, в котором ItemsTemplate будет твой UserControl. Всё. Это самый простой вариант.
Эта вью модель для контрола должна быть в DI как синглтон? Я давно использую разбиение главного окна на отдельные контролы и каждому создаю вью модель и регистрирую их как синглтон, а в главной вью модеи держу ридонли свойства вьюмоделей контролов. Вот хрен знает, правильно я делаю, поэтому и спрашиваю тебя. Вижу ты похожий варик человеку говоришь.
Конечно не синглтон. Да и DI ей делать нечего.
А как тогда? Вью модели вообще не регистрировать в DI?
Зависит. Конкретно vm для этого контрола нет смысла регать, потому что тебе их придётся пачкой создавать. Если хочешь что нибудь зарегать, то зарегай фабрику для этих vm.
Ну вот допустим я создал внутри окна три раздельных контрола со своими вью моделями. Далее я распологаю их в разметке главного окна. Для того чтобы они получали свой датаконтекст я регистрирую вьюмодели этих контролов в di, а в главном окне у свойства datacontext каждого из раздельрых контролов я привязываю к нужной ему вью модели, эти свойства вью моделей контрлов я храню в главной вью модели. Просто я не понимаю, какие ечть альтернативы, если контролы создаются как создается окно и им всем нужен свой DataContext.
Альтернативы есть, как минимум ViewLocator, который сам будет резолвить DataContext для твоих View. В твоём случае можно так делать, если тебе нужен некий "медиатор", который бы разруливал взаимодействия между этими контролами, если оно нужно. Но и для этого есть менее связные механизмы, например message bus. В целом не обязательно хранить vm дочерних view в vm основного окна
Спасибо за совет, обязательно гляну!
Ну я вообще противник viewLocator'ов и в целом Locator'ов) Резолв через DI это ИМХО самое наглядное. Вот в целом самый элементарный ViewLocator, если интересно.
Интерфейсы IControl и IDatatemplate я так понимаю wpf?
Да. Но это штука из темплейта Avalonia. Но не принципиально
Т.е, локаторы как бы есть, но лучше глядеть в более надежные механизмы?
Тут всё зависит от твоих задач. Я стронгли рекомендую посмотреть как делается роутинг в prism. Если тебе нужно просто разезолвить vm для View и не нужно, чтобы какая-то из них имела к другой доступ, если у них нет никаких зависимостей (пустой конструктор), то viewLocator можно рассмотреть как вариант. Я бы прям однозначного ответа не дал. Всё зависит от того, что у тебя там за приложение и вообще логика взаимодействий между view (но моё ИМХО явных связей между vm быть не должно, а всё оно лежать на слое бизнес логики, ну или на message bus'ах)
О, а доступ будет нужен. От состояния коллекции в одной вью модели зависит как минимум доступность выполнения команды в другой.
Обсуждают сегодня