Возникло неполное понимание данной модели, а именно:
Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.
Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

Здравствуйте, kokaku, Вы писали:

K>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.

Изменение VM.

K>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

Если изменяются поля — то сохранение их в M.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, kokaku, Вы писали:

K>>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.

IT>Изменение VM.

K>>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

IT>Если изменяются поля — то сохранение их в M.
А что является "точкой входа"?

Например:

class EmplyeesView {
  clickItem(event) {
    viewModel.openEditor(event.selectedItem)
  }
}

class EmployeesViewModel {
  openEditor(employeeItem) {
    emplyee = emplyeeItem.employee

    editorModel = EditorModel()

    editorViewModel = EditorViewModel()
    editorViewModel.connectModel(editorModel)

    editorView = EditorView()
    editorView.bind(editorViewModel)    
    

    showWindow(editorView)
  }
}

Кому тут передать конкретного emplyee для редактирования? editorModel? editorViewModel? editorView?

PS
По-хорошему, editorView вообще ничего не должен знать про бизнес сущности(Employee)

Здравствуйте, kokaku, Вы писали:


K>Кому тут передать конкретного emplyee для редактирования? editorModel? editorViewModel? editorView?

1. Лучше пользоваться командами и байдингами к ним в View/ViewModel, соответственно у тебя команда по клику будет байндиться к команде, которая обернет метод. Лучше пользуйся фреймворками для реализации.
2. У тебя будет EmployeeViewModel, которого ты передаешь в EditorViewModel.
3. Лучше делигировать кому-то показ окон в зависимости от подхода.


K>По-хорошему, editorView вообще ничего не должен знать про бизнес сущности(Employee)

Именно потому и нужен EmployeeItemViewModel, который будет условной dto-шкой.

Здравствуйте, IncremenTop, Вы писали:

IT>Здравствуйте, kokaku, Вы писали:


K>>Кому тут передать конкретного emplyee для редактирования? editorModel? editorViewModel? editorView?

IT>1. Лучше пользоваться командами и байдингами к ним в View/ViewModel, соответственно у тебя команда по клику будет байндиться к команде, которая обернет метод. Лучше пользуйся фреймворками для реализации.
IT>2. У тебя будет EmployeeViewModel, которого ты передаешь в EditorViewModel.
IT>3. Лучше делигировать кому-то показ окон в зависимости от подхода.


K>>По-хорошему, editorView вообще ничего не должен знать про бизнес сущности(Employee)

IT>Именно потому и нужен EmployeeItemViewModel, который будет условной dto-шкой.

п1 — вопрос не конкретно С#
п3 — тут все понятно, да. Пример для краткости.
п2 — те получается, передавать что-либо нужно во ViewModel ?!

Я правильно понимаю, в нашем примере, если редактору сотрудника потребуется "навыки" сотрудника, то
EditorViewModel имея конкретного сотрудника(пока не важно в каком виде будь-то Employee или EmplyeeViewModel),
загрузит их через EditorModel передав ему необходимые параметры(например emplyeeId или саму сущность)?

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

короче, забей на MVVM и просто попытайся написать юнит-тест, который тестирует, что если ты в формочке из списка выбрал сотрудника номер два и его изменил, то он, на самом деле, был изменён; когда ты начнёшь видеть грабли юнит-тестa, тогда ты увидишь и способы их обходить, причём ничего запоминать не надо будет

Здравствуйте, takTak, Вы писали:

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

T>короче, забей на MVVM и просто попытайся написать юнит-тест, который тестирует, что если ты в формочке из списка выбрал сотрудника номер два и его изменил, то он, на самом деле, был изменён; когда ты начнёшь видеть грабли юнит-тестa, тогда ты увидишь и способы их обходить, причём ничего запоминать не надо будет

Не понял о чем Вы, но все равно спасибо!

Здравствуйте, kokaku, Вы писали:


K>п2 — те получается, передавать что-либо нужно во ViewModel ?!

Да, потому что ViewModel — это состояние нашей вьюшки, в данном случае редактора.

K>загрузит их через EditorModel передав ему необходимые параметры(например emplyeeId или саму сущность)?

Да, V контактирует с VM, VM c M.

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

T>>короче, забей на MVVM и просто попытайся написать юнит-тест, который тестирует, что если ты в формочке из списка выбрал сотрудника номер два и его изменил, то он, на самом деле, был изменён; когда ты начнёшь видеть грабли юнит-тестa, тогда ты увидишь и способы их обходить, причём ничего запоминать не надо будет

K>Не понял о чем Вы, но все равно спасибо!

возьми и просто напиши юнит-тест на предмет того, что ты тут спрашивал: выборку одного сотрудника из листа или чего там было? Знаешь, что такое юнит-тест?

Здравствуйте, kokaku, Вы писали:

K>Возникло неполное понимание данной модели, а именно:
K>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.
K>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

Вот иллюстрация. Прояснилось? Нужно самому написать все от и до по примеру, тогда проясниться. Скорее даже не с первого раза.

Здравствуйте, licedey, Вы писали:

L>Здравствуйте, kokaku, Вы писали:

K>>Возникло неполное понимание данной модели, а именно:
K>>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.
K>>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

L>Вот иллюстрация. Прояснилось? Нужно самому написать все от и до по примеру, тогда проясниться. Скорее даже не с первого раза.

L>Image: image2.png

Схему то я понимаю
Не совсем понимаю кто знает про....как же это правильно выразиться...передачу параметров.
Возвращаясь к начальному примеру: нужно открыть редактор "сотрудника", для этого у нас есть EmployeeView, EmployeeViewModel и EmployeeModel.
Кому из этой тройки, нужно передать employeeId?

Здравствуйте, kokaku, Вы писали:
K>Схему то я понимаю
K>Не совсем понимаю кто знает про....как же это правильно выразиться...передачу параметров.
K>Возвращаясь к начальному примеру: нужно открыть редактор "сотрудника", для этого у нас есть EmployeeView, EmployeeViewModel и EmployeeModel.
K>Кому из этой тройки, нужно передать employeeId?
Эмм, наверное — никому. EmployeeId зашивается в EmployeeModel при её инициализации, и более не меняется.
EmployeeViewModel связана с конкретной EmployeeModel.
EmployeeView — с EmployeeViewModel. Зачем им EmployeeId?

Здравствуйте, kokaku, Вы писали:

K>Здравствуйте, licedey, Вы писали:

L>>Здравствуйте, kokaku, Вы писали:

K>>>Возникло неполное понимание данной модели, а именно:
K>>>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.
K>>>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

L>>Вот иллюстрация. Прояснилось? Нужно самому написать все от и до по примеру, тогда проясниться. Скорее даже не с первого раза.

L>>Image: image2.png

K>Схему то я понимаю
K>Не совсем понимаю кто знает про....как же это правильно выразиться...передачу параметров.
K>Возвращаясь к начальному примеру: нужно открыть редактор "сотрудника", для этого у нас есть EmployeeView, EmployeeViewModel и EmployeeModel.
K>Кому из этой тройки, нужно передать employeeId?

У нас в проекте передача параметров производилась в command.
Command, которая открывает редактор, передает нужные параметры ViewModel(в вашем случае в EmployeeViewModel)

Здравствуйте, Sinclair, Вы писали:

S>Эмм, наверное — никому. EmployeeId зашивается в EmployeeModel при её инициализации, и более не меняется.
S>EmployeeViewModel связана с конкретной EmployeeModel.
S>EmployeeView — с EmployeeViewModel. Зачем им EmployeeId?
Это как раз суть моего вопроса
Вы предлагаете в Model.
В вашем случае ViewModel ничего не знает по конкретный Employee, employeeId и тп.
Например: нужно показаться текущие скилы сотрудника, ViewModel тупо вызовет Model::loadSkills(),
а та уже по "зашитому" в нее EmployeeId загрузит нужные данные.
Этот вариант мне нравится больше.


Здравствуйте, Sitrix, Вы писали:
S>У нас в проекте передача параметров производилась в command.
S>Command, которая открывает редактор, передает нужные параметры ViewModel(в вашем случае в EmployeeViewModel)
Вы предлагаете в ViewModel
Из примера выше(загрузка скилов), ViewModel должна будте вызывать методы Model с параметрами,
связанными с Employee — Model::loadSkills(int employeeId) или Model::loadSkills(Employee employee)
Или можно пробросить нужные параметры дальше в Model.

Курю дальше

K>Здравствуйте, Sitrix, Вы писали:
S>>У нас в проекте передача параметров производилась в command.
S>>Command, которая открывает редактор, передает нужные параметры ViewModel(в вашем случае в EmployeeViewModel)
K>Вы предлагаете в ViewModel
K>Из примера выше(загрузка скилов), ViewModel должна будте вызывать методы Model с параметрами,
K>связанными с Employee — Model::loadSkills(int employeeId) или Model::loadSkills(Employee employee)
K>Или можно пробросить нужные параметры дальше в Model.

K>Курю дальше

ViewModel может и должна оперировать данными модели. В модель можно вынести какие-то общие методы/классы

Здравствуйте, kokaku, Вы писали:

K>Здравствуйте, licedey, Вы писали:

K>Схему то я понимаю
K>Не совсем понимаю кто знает про....как же это правильно выразиться...передачу параметров.
K>Возвращаясь к начальному примеру: нужно открыть редактор "сотрудника", для этого у нас есть EmployeeView, EmployeeViewModel и EmployeeModel.
K>Кому из этой тройки, нужно передать employeeId?

В EmployeeView у тебя может быть обработчик, вроде OnMouseDown, OnKeyDown, ButtonCLick, в котором ты собственно обращаешься к EmployeeViewModel объекту.
Который храниться в EmployeeView.DataContext. А уже EmployeeViewModel, содержит объект EmployeeModel, из которого берешь EmployeeId.
От View можешь извлекать например SelectedItem в ListBox'e, который содержит список из EmployeeViewModel.

Здравствуйте, kokaku, Вы писали:

K>Не совсем понимаю кто знает про....как же это правильно выразиться...передачу параметров.
K>Возвращаясь к начальному примеру: нужно открыть редактор "сотрудника", для этого у нас есть EmployeeView, EmployeeViewModel и EmployeeModel.
K>Кому из этой тройки, нужно передать employeeId?

Зависит от схемы навигации, принятой в приложении.
Сама по себе тема холиварная: кто-то кричит, что дрвайвить навигацию должна вьюмоделька; кто-то настаивает на вынесении навигации во внешний фреймворк; кто-то кричит что навигация — это состояние, поэтому должна быть выражена в модели. Каждый в чём-то прав, но истина где-то рядом.

K>Возникло неполное понимание данной модели, а именно:
K>Есть окно со списком сотрудников. Выбираем сотрудника для редактирования.
K>Вопрос: кому мы передаем сотрудника в редактор, View, ViewModel или Model?

Здравствуйте!

Я тоже подошел к похожей проблеме.

Вы нашли какое-то решение?

Редактирование сотрудника должно открыться в отдельном окне?
Если да, то мне кажется, ViewModel должна создать некий новый объект типа EmployeeEditController и передать ему EmployeeID из EmployeesModel.
Этот EmployeeEditController должен сформировать новый editorEmployeeView, EditorEmployeeModelView и т.д. и про-инициализировать их.