«Золотая» реализация для MVVM Light

Question

Вопрос можно резюмировать следующим образом: Каков наилучший способ разработки понятного приложения для UWP с MVVM Light? Может быть, я пропустил это, но я не нашел образец или подобный ...

Я видел много обсуждений и изменений: Модель - я помещаю здесь только данные, или я должен создать модель электронного DAL? Если я использую EF, мне нужно 2 слоя (DAL и модель)?

Должно ли это быть наблюдаемым? Методы загрузки / сохранения или заполнения должны быть здесь или в DAL?

Затем мы переходим на более высокий уровень: если у вас есть список в классе (например, компания - сотрудник), объект List находится в модели или во ViewModel?

Но если у меня есть Модель компании и список компаний (Список), собранный через LINQ на EF, как мне преобразовать это в ObservableCollection<CompanyViewModel>? я должен сделать цикл и добавить новые объекты? не очень эффективен и хорош ... разве нет лучшего способа?

Модели поднимают ContentChanged? (мне кажется, что ответ будет отрицательным, он должен подниматься моделью представления)

Для ViewModel вы отображаете модели представления на основе представлений (таким образом, основная форма ViewModel, TreeView ViewModel) или наданные (CompanyViewModel)? или и то, и другое (в данном случае, почему?)?

Все ViewModels должны быть наблюдаемыми, поэтому все действия должны вызывать изменение контента здесь или ниже?

Я видел все возможные ответы, поэтому яспрашиваю :;какой "золотой" путь? «лучшая практика»? Я знаю, что почти все они «могут работать», но моя цель - узнать «лучшее» (= более эффективно, чисто с точки зрения дизайна и т. Д.).

Answer 1

В случае распространения изменений в источнике данных в пользовательском интерфейсе, предлагаемое вами решение циклического добавления и добавления новых объектов не так плохо, как кажется. Если ваш источник данных содержит свойство «последнее изменение», которое позволит вам фильтровать только реальные изменения, вы можете получить только измененные данные. В противном случае, вы все равно должны запросить полное количество элементов, поэтому повторный цикл по данным не изменит сложности (все еще линейно с количеством элементов). Если у вас есть какие-то идентификаторы, вы можете просто проверить, присутствует ли такой идентификатор в ObservableCollection и затем добавить его.

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