WPF: MVVM и редактирование иерархических данных - PullRequest
4 голосов
/ 11 сентября 2009

Я все еще пытаюсь обернуть голову вокруг MVVM. Допустим, у меня есть модель, которая выглядит примерно так:

public class Company  
{  
    public IList<Division> Divisions { get;set;}  
}

public class Division  
{  
    public string Name { get;set;}
    public IList<Department> Departments { get;set}
}  

public class Department
{
    public string UnitNumber { get;set;}
    public string DepartmentName { get;set;}
    public IList<Employee> Employees { get;set;}
}

public class Employee
{
    public string FirstName { get;set;}
    public string LastName { get;set;}
    public string JobTitle { get;set;}
}

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

public class CompanyViewModel : INotifyPropertyChanged
{
    private Company _company;
    public Company Company
    {
         get { return _company;}
         set { _company = value; NotifyPropertyChanged("Company");}
    }
}

Теперь в моем представлении (WPF) я бы установил контекст данных для ViewModel, и выбранная сетка данных будет привязана к пути «Company». Пока все замечательно ... У меня хороший интерфейс для развёртывания / свертывания в отделы, отделы, сотрудников ...

За исключением:

  1. Что, если сетка редактируемая ... Имена отделов можно изменять (и проверять с помощью ViewModel, то же самое для имен сотрудников).

  2. Что, если я хочу добавить новых сотрудников, отделы и т. Д., Все это должно быть отражено в сетке без повторного связывания (в этом и заключается смысл привязки данных WPF?)

Потенциальное решение:

У вас есть отдельный класс ViewModel для каждого класса домена ...

Это, похоже, подразумевает много отображений из DTO -> ViewModel, дублирование (потому что они почти одинаковые объекты, но все же не совсем.) Учитывая, что я, вероятно, уже сопоставляю из какой-то сущности ORM -> DTO в сервисная сторона, отправляющая его по проводам (WCF) клиенту, отображающая каждую иерархию DTO в свою собственную ViewModel, является сложным и дорогостоящим процессом (не говоря уже о работе, связанной с этим).

Кровотечение таких вещей, как INotifyPropertyChanged, ObservableCollection и т. Д., В мои DTO выглядит как хак.

У кого-нибудь есть лучшее решение? Я сумасшедший? ; -)

Ответы [ 2 ]

3 голосов
/ 11 сентября 2009

«Выливание таких вещей, как INotifyPropertyChanged, ObservableCollection и т. Д. В мои DTO, выглядит как хак».

Я чувствую твою боль, но такой подход я применил к нескольким проектам.

Итог: для привязки данных WPF к «работе», как объявлено, объекты / коллекции, к которым вы привязываете, должны поддерживать INotifyPropertyChanged и ObservableCollection.

Лично я думаю, что создание DTO, поддерживающих это, - это МНОГО меньше работы, чем постоянный перевод данных назад и вперед в модель представления или другой промежуточный объект, который по сути является более богатой версией объекта DTO.

1 голос
/ 11 сентября 2009

Если вам надоело набирать код для INotifyPropertyChanged и вы также используете автоматические свойства, почему бы не взглянуть на Силовые игрушки MoXAML , которые позволяют преобразовывать автоматические свойства в уведомляемые?

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