Должен ли я писать классы для элементов управления WPF? - PullRequest
1 голос
/ 26 февраля 2012

У меня есть сетка, которую я называю, скажем, FooHistory.Теперь мне нужно много функциональности, связанной с этим, поэтому я продолжаю и создаю класс FooHistory.Теперь у меня есть класс FooHistory и элемент управления.

В моем конструкторе MainWindow я создаю новый экземпляр этого класса и передаю экземпляр this (то есть MainWindow) в FooHistory класс вроде инъекции зависимостей.Затем, когда класс FooHistory хочет взаимодействовать с элементом управления FooHistory, я делаю что-то вроде this.mainWindow.FooHistory.Items.Add(...).

Мой вопрос заключается в том, является ли это рекомендуемым способом написания приложений WPF или мне не хватает некоторыхфундаментальные подходы?

Ответы [ 4 ]

1 голос
/ 26 февраля 2012

Мы используем для наших программ подход MVVM. Хотя детали могут отличаться от программы к программе, MVVM обычно состоит из 3 основных частей.

Модель: Это ваш объект данных. Это могут быть бизнес-данные, такие как

class Account
{
    string Name {get;set;}
    string Address {get;set;
}

, но также могут быть данные пользовательского интерфейса, такие как:

class Window
{
    Point Position {get;set;}
    Size Size {get;set;}
}

Эти объекты предназначены для хранения данных, не более того. Нет событий, нет команд, нет методов (Это одна точка, в которой различаются интерпретации MVVM).

ViewModel: Это должно обернуть модель и обеспечить логику вокруг базовой модели. Этот класс также используется для преобразования свойства бизнес-модели в понятное свойство представления.

class AccountViewModel
{
    public AccountViewModel(Account aWrappedModel)
    {
    }

    string Name {get {return Model.Name;} }

    AddressObject Address { get{ return new AddressObject( Model.Address ); }
}

Вид:

Является ли частью wpf это пользовательские элементы управления, пользовательские элементы управления, окна, шаблоны данных и т. Д. Несмотря на распространенное мнение, хорошо иметь код позади для просмотра, в противном случае вам придется наклоняться над обратными словами только потому, что вы слышали, что у представления не может быть кода.

Обычный подход теперь состоит в том, чтобы создать модель, одну или несколько моделей представления и установить эти модели представления как DataContext в вашем представлении. Иногда вам нужен DataTemplate для отображения данных, например, DataTemplate для нашей AccountViewModel.

<DataTemplate DataType="{x:Type AccountViewModel}">
    <StackPanel>
        <TextBox Text="{Binding Name}/>
        <Button Content="Save" Command="{Binding SaveAccount}"/>
    </StackPanel>
</DataTemplate>

Эта конструкция интенсивно использует привязку данных, которая является фундаментальной для MVVM и работает довольно хорошо. Конечно, может возникнуть пара проблем: Как работать с коллекцией с моделями? Как обрабатывать события в моделях просмотра, поступающих из интерфейса? Как хранить мои данные?

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

1 голос
/ 26 февраля 2012

То, что вы описали, звучит как некий паттерн Model-View-Presenter, вариант MVC. Поскольку это определенно хороший шаблон, особенно для ASP.NET и WinForms, он не использует некоторые основные концепции WPF.

То, что вам не хватает, называется Привязка данных и Команды. Помимо этого, появился новый вариант MVC - Model-View-ViewModel (MVVM), иногда называемый Presentation Model. Грубо объяснил: Ваше окно называется видом. Логика Youd Busines заключена в модели. Вы создаете класс ViewModel, который предоставляет некоторые свойства, которые являются представлением модели для конкретного вида. ВМ должна также реализовать INotifyPropertyChanged, чтобы обеспечить способ уведомления пользовательского интерфейса об изменениях данных. Вы выставляете операции таким же образом - с помощью свойства типа ICommand. В конструкторе View вы пишете что-то вроде this.DataContext = new ViewModel() Затем вы связываете свойства элементов управления View и ViewModel, используя синтаксис {Binding PropName}.

Возможно, вы также захотите проверить некоторые фреймворки для MVVM, такие как Prism , MVVM Light .

Вот пример: http://rachel53461.wordpress.com/2011/05/08/simplemvvmexample/

1 голос
/ 26 февраля 2012

если большая часть вашей функциональности представляет собой логику представления, вы можете создать пользовательский элемент управления (путем создания подкласса UserControl) и иметь пару файлов .xaml и .xaml.cs и поместить логику представления в файл .xaml.cs.file.

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

, если вы можете избежать передачи дерева элементов управления (например, SomeWindow.ParentControl.ChildControl.Items), это сделает вашу жизнь проще.

0 голосов
/ 26 февраля 2012

Да, вы можете ...... но делать это не нужно ........... альтернативный путь .........

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...