Логика, предполагающая обработку данных (из БД) во ViewModel или Model?

Question

Я занимаюсь разработкой приложения с использованием WPF. Шаблон, который я использую для этого, очевидно, MVVM. Также я использую Entity Framework ORM и LINQ-to-Entities для запроса объектов EF.

Мое понимание MVVM состоит в том, что представление не должно иметь никакого кода, и только знание, которое он должен иметь о ViewModel, состоит в том, что ViewModel содержит определенные свойства, с которыми связан View, а также содержит команды для обработки событий представления. , В то время как Модель содержит только код для получения данных из БД.

В моих модельных классах я только что написал функции, которые напрямую запрашивают объекты EF, используя Linq-to-entity. Обработка, которую мне нужно выполнить для данных перед назначением их свойствам в ВМ, присутствует либо в ВМ, либо в классах, присутствующих в проекте ВМ. Просто упомянуть здесь, что у меня есть 3 проекта - View, ViewModel и Model.

Мой вопрос здесь заключается в том, могу ли я сохранить эти функции (которые включают обработку данных из БД) в проекте VM или это должно быть в проекте Model? Если в проекте ViewModel он должен находиться в соответствующей виртуальной машине или в отдельных классах, присутствующих в проекте виртуальной машины?

Answer 1

Одной из часто используемых практик является делегирование бизнес-логики на уровень обслуживания и выполнение бизнес-логики с использованием шаблона репозитория. Как упомянуто в других ответах, ViewModel должен украсить модель определенными свойствами представления и командами, которые обрабатывают взаимодействия пользовательского интерфейса. По своему определению Модель должна иметь всю логику для манипулирования данными.

Если вы следуете сервисно-ориентированной архитектуре, тогда ViewModel может быть добавлен с сервисом. Служба отвечает за выполнение бизнес-функций. Эти бизнес-функции в основном выполняются на постоянных данных. И эту логику можно прекрасно абстрагировать с помощью любых инструментов и технологий ORM, таких как EF или NHibernate. Вы можете выполнить поиск в Google по шаблону репозитория, который может быть полезен, если вы следуете этой архитектуре.

Нет необходимости использовать шаблон репозитория, если он вам не нужен. Вы по-прежнему можете использовать EF непосредственно со своего уровня обслуживания. Преимущество наличия репозитория заключается в том, что он действует как отображение между уровнем персистентности (база данных) и уровнем домена (модель).

Надеюсь, это поможет.

Answer 2

Ответственность: Модель -> получать данные из БД, службы и т. Д. И предоставлять данные через доменные объекты.Не касается того, как будут отображаться данные.Относится только к бизнес-логике с объектами домена.

ViewModel -> считывает данные из модели и украшает их, чтобы они могли отображаться в представлении в правильном формате.Expose Свойства, которые View может связать для извлечения данных.Также Expose Commands, что представление может вызывать пользовательские вводы.

View -> в соответствии с данными, полученными от VM через DataBinding, отобразить данные, используя хороший DataTemplate или UserControl.Привязка к командам VM для вызова пользовательских вводов.

В идеале ViewModel занимается только отображением данных в пользовательском интерфейсе, а не изменением модели.Он получает объект модели в своем конструкторе и предоставляет свойства для использования представлением через привязку данных.Модель не знает о ViewModel.Всякий раз, когда данные модели изменяются, ViewModel может уведомляться об изменениях либо событием, генерируемым моделью, на которую подписывается ВМ.Или виртуальная машина должна запрашивать модель всякий раз, когда представление вызывает средство получения свойств в виртуальной машине для данных.

Модель должна предоставлять свойства независимо от того, как они будут отображаться.Так что не стоит делать какую-либо обработку по свойствам.ViewModel может украшать данные, полученные от Model, согласно требованию View.

Answer 3

По моему мнению, лучше перенести функции обработки базы данных в проект Model, поскольку вполне возможно, что на ViewModel будет возложена слишком большая ответственность.

Я попытаюсь показать пример:

Предположим, у нас есть класс SomeViewModel со свойствами IsHighlited и Item, что-то вроде этого:

class SomeViewModel
{
    public bool IsHighlighted
    {
        get 
        { 
            /* View logic here */
        }
    }

    public SomeClass Item
    {
        get
        {
            /* Retreiveing an item from database */
        }
    }
}

Теперь, когда вам нужно изменить логику представления, вы должны изменить класс SomeViewModel(это нормально), но когда вам нужно изменить логику взаимодействия с базой данных, вам также нужно изменить тот же класс, что еще не так хорошо.

Принцип единой ответственности гласит:

Никогда не должно быть более одной причины для изменения класса.

В результате, если вы оставите все как есть, вы можете столкнуться с ненужной большой сложностьювашего кода в будущем.

Answer 4

Они должны быть в проекте Model, ViewModel - это просто представление того, что ожидает ваш View, ничего более.

Answer 5

Вас может заинтересовать BookLibrary пример приложения WPF Application Framework (WAF) .В нем показано, как использовать Entity Framework вместе с шаблоном MVVM.