Приложение. Ресурсы для хранения данных приложения

Question

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

Практика, на которую я ссылаюсь, заключается в том, что я новичок в WPF, как и яИдя дальше, я обнаружил, что удобно и полезно помещать строки, документы и доменные объекты в Application.Resources в app.xaml, когда их данные требуются для всего приложения, и для простоты привязки статического ресурса при помощих: ключ.

Хорошо?Плохой?Зачем?Что я должен сделать вместо этого?Пожалуйста, не дайте ссылки на крупные учебные пособия по MVVM и тому подобное, просто ищите краткий ответ относительно этой конкретной практики, если у MVVM есть ответ на него, я рад слышать, что это такое, я просто не хочу читать учебник из 6 страницили блог, чтобы узнать ..

Answer 1

Это имеет смысл для тех, кто используется в приложении - «не повторяйся». Я также рекомендовал бы иметь ресурс для конкретного проекта, который объединяет ресурсы приложения. Элементы управления должны ссылаться на это, а не на ресурсы приложения.

Это делает элементы управления в проекте более автономными.

Я бы также рекомендовал разбивать ресурсы на логические группы и объединять их, вместо того, чтобы иметь «одно большое ведро».

Answer 2

Я реализую объект модели представления приложения (AVM). Все, что должно быть открыто для представлений приложения в глобальном масштабе, реализуется как свойство в модели представления приложения, чтобы я мог получить к нему доступ через привязку. Это обеспечивает хороший согласованный метод доступа, обеспечивает тестируемость, реализует уведомления об изменении свойств, дает мне место для размещения команд всего приложения, всего того, что вы ожидаете от использования модели представления.

Контекст данных для каждого окна верхнего уровня устанавливается на экземпляр модели представления приложения. Поэтому мне не нужно возиться со словарем ресурсов или запоминать значения ключей вообще. Поначалу это может показаться немного странным - почему два окна используют одну и ту же модель вида? - но если вы хотите поместить одну и ту же команду File/Exit в каждое окно, которое запускает приложение, это на самом деле имеет логический смысл. В таком случае контекст данных окна устанавливается на AVM, и затем он содержит панель, контекст данных которой установлен на свойство на AVM, которое является фактическим контекстом для этого окна. Пока вы называете свой элемент окна именем, привязка к объектам в AVM тривиальна - {Binding ElementName=TheWindow, Path=DataContext.TheProperty} - или вы можете представить AVM как свойство моделей дочерних представлений.

Шаблон AVM подвержен тем же подводным камням, что и любой шаблон «один объект для правила» - например, создание дрожащего зверя с 200 несвязанными свойствами. Решение то же самое: объединить эти свойства в классы обслуживания.

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

Answer 3

Помещение вещей в App.xaml может быть проблемой, когда:

1. Вы начинаете разветвлять ваше приложение на отдельные сборки, так как сборки не могут "видеть" время разработки app.xaml - вы можете найти толькоошибки во время выполнения.
2. У вас есть волшебная строка для указания на ваш ресурс, которую легко ошибиться - или, что еще хуже, дублировать случайно.
3. Позже трудно найти местаданный ресурс используется и может ли он быть безопасно изменен («Для чего он был UpdateFrequency ...»)
4. Вы хотите, чтобы он был настраиваемым - часть AppSettings файла app.config намного лучшенастройки такого типа.

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

РЕДАКТИРОВАТЬ: Вещи, которые я предпочитаю иметь в App.Xaml:

• Глобальные стили и шаблоны данных - другими словами - вещи, используемые для визуального представления, которые используются для переопределения «стандартных» настроек - поэтому обычно у них нет тега x: Key, но rather a TargetType = "{x: Type SomeType}"

Надеюсь, это поможет!