WPF / MVVM - нужно ли создавать разные классы для каждой модели представления? - PullRequest
Новая
       20

WPF / MVVM - нужно ли создавать разные классы для каждой модели представления?

2 голосов
/ 12 июня 2010

Я пытаюсь привести пример из отличного видео "Как я" для MVVM Тодда Миранды, найденного в MSDN.

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

  1. В этом примере у него есть ViewModel с именем EmployeeListViewModel .Теперь, если я хочу включить Отделы, я должен создать другую ViewModel, такую ​​как DepartmentListViewModel ?

  2. В примере EmployeeRepository в качестве источника данных.В моем случае я пытаюсь использовать объект Entity в качестве источника данных ( Employees.edmx в папке Model и EmployeeRepository.cs в DataAccess папка).Если я хочу отобразить список отделов, должен ли я создать отдельный класс с именем DepartmentRepository и поместить туда все определения методов, связанных с отделами?

  3. Что если я хочу получить имя сотрудника и название его отдела вместе?Где мне разместить методы для этого?

Я очень новичок в WPF и MVVM, и, пожалуйста, дайте мне знать, если что-либо из перечисленного необходимо перефразировать.

Спасибо за помощь.

Ответы [ 3 ]

2 голосов
/ 12 июня 2010

Да, как правило, каждый View (страница, окно, экран) должен иметь свою собственную ViewModel. Таким образом, если вы хотите иметь экран со списком некоторых сотрудников, ваша ViewModel будет иметь некоторую коллекцию сотрудников (IEnumerable) в качестве свойства. Ваш тип сотрудника будет содержать свойства для их имени, отдела, номера телефона (и т. Д.).

Мне не совсем понятно из вашего вопроса, хотите ли вы отобразить список сотрудников и отделов на одной странице. Если это то, что вы пытаетесь сделать, то в вашей ViewModel у вас будет два свойства, которые представляют собой такие коллекции: 

public class EmployeeListViewModel {
     public IEnumerable<Employee> Employees { get; set; }
     public IEnumerable<Department> Departments { get; set; }
}

... что позволит вам отображать обе коллекции на вашем представлении.

1 голос
/ 12 июня 2010

Здесь нет жестких и быстрых правил. Я буду решать каждую проблему индивидуально:

  1. У вас будет одна ViewModel для каждого уникального View, который вы имели. Я думаю, что вызов его [Entity] ListViewModel мог бы запутать проблему. Назовите его именем представления ... если вы смотрите на DepartmentDashboard, назовите его DepartmentDashboardViewModel.
  2. Для вашей модели нет никаких правил, и, конечно, не должно быть соотношения объектов модели 1: 1: 1 для просмотра моделей и представлений. Обычно у меня есть одна установка OR / M при работе непосредственно с базой данных (например, TheBigDatabase.edmx), и это происходит из многих моделей (сотрудники, отделы, счета, транзакции и т. Д.). Делай то, что тебе нравится.
  3. Поскольку вы собираетесь создать edmx с несколькими сущностями (как я предлагал в # 2), вы сможете воспользоваться связями между этими сущностями (сотрудники, как я полагаю, имеют отделы, так что сотрудник). Департамент будет там). Если у вас есть это, вы можете отобразить связанные данные в одном месте, если хотите.
1 голос
/ 12 июня 2010

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

В вопросе 2, что я иногда делаю, это извлекаю и IQueryable, а затем "переводю" возвращаемый объект в ViewModel. Репозитории / Домен не должны ничего знать о ViewModels, поскольку это просто презентация.

Отвечая на пункт 3, если вам нужно связать элемент управления с сотрудником и отделами вместе, Может быть, вы можете сделать что-то вроде этого: 

public class EmployeeDepartmentsViewModel : BaseViewModel //Base View Model has INPC stuff
{
    public Employee Employee { get; set; }
    public Department Department { get; set; }
}

Надеюсь, это прояснит ваши сомнения.

...