bnmc Ответов: 1

Как структурировать viewmodels и модели с вложенными observablecollections

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

Приложение предназначено для просмотра билетов технической поддержки из базы данных SQL2000. Коллекция билетов имеет отдельные коллекции событий, эскалаций и RMA. Один билет может относиться к нулю или более событий, эскалаций или RMA. Чтобы сделать это немного сложнее, я не просто показываю коллекции с тем, что я извлекаю из базы данных, я также предоставляю сводные и общие свойства, которые я хочу отобразить в DataGrid.

У меня есть MainWindow окно просмотра), TicketsView (UserControl), и TicketView (элемент управления UserControl). Они соответствуют MainWindowViewModel, TicketsViewModel, и TicketViewModel соответственно. То есть Ticket, Event, Escalation, и Rma Классы моделей; и TicketRepository класс, который взаимодействует с базой данных. Где я должен найти наблюдаемые коллекции и какими должны быть эти коллекции? Я могу создать ObservableCollection<Ticket>; в TicketsViewModel что то TicketsView.TicketsDataGrid привязывается к; и просто создает TicketViewModel когда SelectedItem проходит Ticket объект. Однако это не позволяет мне иметь свойства вычисления / итога в DataGrid.

Любая помощь или руководство будут оценены по достоинству.

Что я уже пробовал:

Я уже пробовал создавать ObservableCollections только с объектом Model и создавать объект ViewModel после того, как SelectedItem передаст класс Model. Работает хорошо, если у меня нет никаких сводных/общих свойств; и если я следую более распространенному мнению о том, чтобы держать эти свойства вне ваших классов моделей.

Затем я создал ViewModels для всего, что требовало этих типов свойств, вместо того чтобы просто создавать их при передаче объекта. Это очень быстро усложняется, и кажется, что это может быть неправильно. Я в порядке, создавая все это. TicketViewModel предметов; так как имеется соответствующий TicketView элемент управления UserControl. У меня нет взглядов, соответствующих EventViewModel, EscalationViewModel, или RmaViewModel; как они только показываются в EventsDataGrid, EscalationsDataGrid, и RmasDataGrid внутри TicketView- Или это нормально? Или же у меня должна быть какая-то другая пользовательская коллекция или оболочка для этих коллекций, которая имеет свойства и объект модели со свойствами, которые я выставляю?

Potu Nani

private ObservableCollection & lt;holiday & gt; _HolidayListCollection;
public ObservableCollection< holiday> HolidayListCollection
{
get { return _HolidayListCollection; }
набор
{
_HolidayListCollection = значение;
On свойство changed();
}
}
и мне это нужно
HolidayListCollection = ClonedHolidayListCollection.Где (y=> y.Праздничный день.Значение.Год.ToString()==SelectedYear) as ObservableCollection & lt;holiday>;
но получить нулевое значение ?

1 Ответов

Рейтинг:
8

Super Lloyd

конечно, давай!
это прекрасно, и даже то, что делают люди

class MyViewModel : ModelBase
{
  public AModel MyProperty
  {
    get { return mProperty; }
    set {
      mProperty = value;
      OnPropertyChanged();
    }
  }
  public ObservableCollection<othermodel> Children { get; } = ObservableCollection<othermodel>
();
}</othermodel></othermodel>


На самом деле вы делаете все, что хотите!
Единственное, что нужно помнить, - это то, что эти "ViewModels" являются моделями для представлений. Таким образом, их (единственным) ограничением является следующее: *если изменение должно быть отражено в представлении, то INotifyPropertyChange или INotifyCollectionChanged (что когда-либо уместно) должно быть уволено вместе с ним*.
Просто так получилось, что
class ObservableCollection<othermodel> : INotifyCollectionChanged</othermodel>

bnmc

Спасибо за ответ, супер Ллойд. Удивительно, что эта концепция мало обсуждается и только кажется замалчиваемой. И аргумент многих разработчиков о том, где найти некоторые вещи, связанные с MVVM, затрудняет эту работу. Спасибо, что подтвердили, что это принято.

Наконец-то я нашел статью, на которую раньше не натыкался. В нем обсуждается именно это, о том, что ответчик нашел запутанным. В частности, " другой вид объекта, который помещается в слой ViewModel, - это оболочка вокруг объекта модели, которая придает ему поведение и делает его более удобным для использования в представлении..." Далее автор упоминает о" толстых "и" тонких " слоях ViewModel. Я настоятельно рекомендую прочитать его ответ, так как он также имеет очень хорошее объяснение.

http://stackoverflow.com/a/5422692/4429864

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

Super Lloyd

Пожалуйста! :)
MVVM может показаться сначала запутанным... но он станет великим, как только вы его поймете! :)
Не думаю, что это других! ;)

Просто подумайте об этом как о MV (Model-View) VM (ViewModel) - это просто оболочка вокруг модели, чтобы дополнить ее событием изменения и добавить свойство, не относящееся к модели, например общественный метод ICommand Кнопкой

И это становится очень легко, как только вы овладеете им, потому что:
1. существует (почти) достаточная поддержка встроенного XAML, чтобы сделать это относительно легко (вам придется добавить некоторый вспомогательный код, такой как знаменитый DelegateCommand)
2. разделение пользовательского интерфейса и модели "despaghettify" вашего кода

Не беспокойтесь слишком много о большой концепции, такой как" разделение интересов", простота должна быстро стать очевидной. если это не после 1 или 2 проекта, откажитесь от него. Это может помочь вам понять! ;)