2013-02-18 4 views
1

Если я поместил коллекцию Observable в отдельный файл .cs (class) и использую ее в своем MainPage.xaml, как я могу сделать так, чтобы все данные, хранящиеся внутри этой же Observable Collection доступен через другую страницу XAML позднее?App-wide Observable Collection

E.g.

MyClass.cs: 
public ObservableCollection<String> oC = new ObservableCollection<String>(); 

MainPage.xaml.cs: 
// add to observable collection 

SecondPage.xaml.cs: 
// access and use data stored in ObservableCollection 

ответ

0

Я думаю, что вы просто хотите:

MyClass.cs: 
public static ObservableCollection<String> oC = new ObservableCollection<String>(); 

MainPage.xaml.cs: 
// add to observable collection 

SecondPage.xaml.cs: 
// access and use data stored in ObservableCollection 

После oC является статическим, вы можете ссылаться на него снова и снова из любого класса/страницы.

Однако, если вы хотите связать с ним (так как вы не можете связать с полями или для статических свойств в Windows 8 приложений), вы должны иметь, что ссылка XAML страницу вашего статического свойства в простое свойство:

SecondPage.xaml.cs: 
public static ObservableCollection<String> oC { get { return MyClass.oC; } } 

Надеюсь, это имеет смысл!

3

Вы можете объявить коллекцию статическим членом.

Или реализовать одноэлементный узор.

Когда вы привязываетесь к коллекции в XAML, вам необходимо создать аксессор в вашей модели просмотра.

public ObservableCollection<String> Accessor 
{ 
    get 
    { 
    return MyClass.oC; 
    } 
} 
2

Простой способ объявить его статическим и доступ к нему с помощью типа, а не, например:

например,

class SomeClass 
{ 
    public static bool SomeBool = false; 
} 

class SomeOtherClass 
{ 
    public void SomeMethod() 
    { 
     Debug.Write(SomeClass.SomeBool); // Ouput = false 
    } 
} 

Имейте в виду, что эта наблюдаемая будет статична и, следовательно, один экземпляр - любые изменения в нем будут заметны сразу ко всем объектам доступа к ней - это означает, что если какой-то код итерация наблюдаемым и еще пытается добавить/удалить из него - итератор будет сгенерировано исключение

Если это может быть случай, рассмотрим альтернативу или использовать замок, чтобы обеспечить доступ к одной нити к коллекции

+0

Спасибо @Charleh :) Это было неловко задавать этот вопрос. Иногда моя память, похоже, берет отпуск. – Tommy

+0

Не нужно смущаться, это отличный вопрос. Я предпочитаю статические классы самостоятельно для простых проектов. Я свободно называю их «сервисами», такими как ProductService или PackageManager. Они делают весь тяжелый подъем и сохраняют мои ViewModels более стройными. Если ваш проект становится более сложным, и вы обнаружите, что службы начинают зависеть от других сервисов, вы можете рассмотреть возможность перехода к истинному контейнеру IoC и инъекции зависимостей. Но для большинства простых проектов статические классы являются хорошей минимальной эффективной дозой. –

2

Ну как о чем-то вроде этого. Везде доступный ресурс ...

public class CollectionSrc 
{ 
    public ObservableCollection<...> Col 
    { 
    get { return _col ?? (_col = new ObservableCollection<...>()); } 
    } 
} 

В App.xaml

<ns:CollectionSrc x:Key="ColSrc" /> <!--ns .. the namespace of CollectionSrc-->

Теперь вы можете получить доступ к ColSrc везде в коде XAML. Например.

<ListBox ItemsSource={Binding Col, Source={StaticResource ColSrc}} />
+0

Этот шаблон хорош для простых объектов, которые не имеют каких-либо зависимостей от других сервисов и для которых вам не нужен контроль над созданием (он всегда будет создан при загрузке приложения, когда парсер Xaml анализирует App.xaml раздел ресурсов). Если вам нужно больше контролировать, когда объект создается, или если вам нужно задавать зависимости, то синглтон и статические параметры, упомянутые ниже, - ваша лучшая ставка. Поскольку вопрос касался простого ObservableCollection, этот метод работает достаточно хорошо. –

+0

Я бы сказал, что это лучший вариант в большинстве случаев. Вы можете переименовать 'CollectionSrc' в' ViewModelLocator', и он будет казаться более знакомым. Затем вы также можете назвать его «ServiceLocator», и вы получаете больше от шаблонов. Затем вы можете изменить свои свойства, чтобы использовать какой-то контейнер IoC (Inversion of Control), чтобы метод для извлечения этой коллекции был более настраиваемым, и вы находитесь в шаблонах проектирования nirvana. :) –

+0

@ JaredBienz-MSFT Хм, я действительно не понимаю. Я также могу представить себе гораздо более сложный объект, который показывает более сложное поведение. Можете ли вы показать пример, для которого мое предложение не работает? Дополнительное преимущество, мое решение также работает в более старых версиях SL, хотя в наши дни это не так важно. ; o) – DHN

Смежные вопросы