Обмен мнениями между похожими приложениями WPF

1

Я работаю с двумя приложениями WPF, которые используют одну и ту же базу кода и выполняют в основном те же функции. ApplicationA предназначен для опытных пользователей и содержит все колокола и свистки для каждой поддерживаемой нами функции. ApplicationB - это скорее инструмент конечного пользователя - он выглядит по существу тем же, но некоторые из более сложных функций скрыты от пользователя, чтобы максимально упростить их.

Существует много взглядов, которые почти идентичны в двух инструментах, с той лишь разницей, что мы скрываем несколько элементов управления в ApplicationB. Представления достаточно похожи, что не имеет смысла поддерживать отдельную копию для каждого инструмента. Наши модели просмотра знают, в каком приложении они работают, поэтому мы в настоящее время решаем это, связывая видимость элементов вида со свойствами viewmodel.

Посмотреть:

<SomeControl Visibility="{Binding Path=WhichApp}"> ...

Модель:

public Visibility WhichApp
{
    get
    {
        if (GetApp() == Apps.ApplicationB) return Visibility.Collapsed;
        else return Visibility.Visible;
    }
}

Мне не нравится, что viewmodels несут ответственность за обработку видимости, которая почти по определению является свойством представления. Этот подход также ограничивает возможность повторного использования наших режимов просмотра вне этих двух инструментов.

Меня интересуют любые альтернативные решения, которые помогут мне поделиться мнениями между этими двумя проектами, сохраняя при этом разделение проблем между представлениями и режимами просмотра.

  • 0
    Похоже, вы должны объединить их и просто отслеживать, кто является опытным пользователем, а кто - конечным пользователем.
Теги:
wpf
mvvm

2 ответа

1
Лучший ответ

Я согласен с тем, что что-то такое глобальное для приложения не должно содержаться в каждой модели ViewModel (DRY). Этот тип вещей принадлежит статическому ресурсу в App.xaml(BTW, это не плохой способ выполнить любые глобальные настройки, такие как темы/скины, разрешения/роли текущего пользователя и т.д.).

Просто создайте статический ресурс в App.xaml Application.Resources типа Visibility, а затем привяжите его к коду в App.xaml, используя существующий код, который у вас там есть.

Теперь у вас есть одноразовое рассчитанное и извлеченное, хорошо известное место для доступа к приложению во всем мире, и вашим моделям просмотров не нужно изобретать колесо.

Поделиться
1

Я думаю, что ты на правильном пути. Как насчет изменения свойства в PowerUserMode. Я думаю, что модель представления отвечает за представление представления, если она должна отображаться для опытного пользователя или нет. Представление может привязывать свойства Visibility к элементам управления к свойству PowerUserMode с помощью BooleanToVisibilityConverter.

public bool PowerUserMode
{
    get
    {
        return GetApp() != Apps.ApplicationB;
    }
}

Если вам не нравится соединение с GetApp() и типами Apps вы можете просто PowerUserMode свойство с помощью bool и позволить некоторому другому классу установить PowerUserMode на модели представления, если это необходимо.

Поделиться
  • 0
    Если бы я шел по этому пути, я бы также продвигал это свойство вверх по цепочке наследования ... создавал BaseViewModel или какой-то подобный тип с этим свойством (и любыми другими, которые вам могут понадобиться в нескольких элементах управления / окнах).
  • 0
    Это был мой первоначальный план (размещение свойства bool или enum в нашей базовой view-модели и использование конвертера).

Ещё вопросы

Сообщество Overcoder
Наверх
Меню