MVVM, где установить уровень доступа к данным?

Ответ 1

Я бы добавил еще один слой, по сути, вам нужны данные factory. Вы хотите создать набор классов, которые будут CRUD для базы данных для вас и вернуть очищенные объекты POCO в ViewModel.

Хорошим примером для поиска будет Nerd Dinner. Он охватывает MVC, а не MVVM, но шаблоны очень похожи и способ доступа к данным в этом решении будет хорошей отправной точкой.

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

Ответ 2

Вот как я организовывал проекты MVVM w/LINQ:

Модель. Я думаю о модели как состоянии системы. Он обеспечивает интерфейс для данных и отслеживает состояние системы. Модель не знает о ViewModel или View - она ​​просто предоставляет публичный интерфейс для своих данных и различных событий, чтобы знать, как изменилось состояние, пользователи (обычно ViewModels).

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

Вид. Вид - это реальный внешний вид пользовательского интерфейса. Он содержит все встроенные и настраиваемые элементы управления, их расположение и стиль. Он знает о ViewModel, но только с целью привязки к его свойствам.

Шлюз. Это та часть, которая напрямую решает ваш вопрос. Шлюз (который в основном мой способ сказать "DataAccessLayer" ) - это отдельный отдельный слой. Он содержит весь код (включая запросы LINQ) для CRUD или выбирает, вставляет, обновляет и удаляет данные из/в ваш источник данных (база данных, XML файл и т.д.). Он также предоставляет публичный интерфейс модели, позволяя модели сосредоточиться на поддержании состояния системы, не заботясь о деталях (т.е. Запросах), необходимых для обновления источника данных.

Классы DataAccess. В С# это очень простые классы, которые моделируют ваши объекты элементарных данных. Когда вы выбираете что-то с помощью запроса LINQ, вы обычно создаете IEnumerable<T> или List<T>, где T является одним из ваших объектов данных. Пример объекта данных:

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

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

Недостатком является то, что он может быть чрезмерным для небольших проектов. В итоге вы создаете много инфраструктуры для общедоступных интерфейсов, которые в основном передают одно желание через несколько уровней. Таким образом, у вас может получиться такой сценарий: [пользователь нажимает "Отправить", "ViewModel" указывает Model на AddNewPerson, Model указывает Gateway на InsertPerson] вместо сценария, подобного этому [пользователь нажимает "Отправить", "ViewModel" добавляет новую запись в базу данных напрямую].

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

Ответ 3

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

Используйте какой-либо сопоставитель для сопоставления вашей модели представления (VM в MVVM) с вашей моделью (первый M). Новые объекты в вашей модели могут быть созданы с использованием шаблона factory. После создания вы можете сохранить их в базе данных с использованием шаблона репозитория. Затем хранилища будут представлять ваш уровень доступа к данным. В вашем репозитории вы можете использовать сопоставитель O/R, такой как NHibernate или Entity Framework.

EDIT:
Я вижу, что GraemeF предлагает ввести код доступа к данным в модель. Это НЕ хороший подход, так как это заставит вас обновить вашу модель домена, если вы должны перейти от, например, SQL Server для Oracle или XML файлов. Объектам домена не нужно беспокоиться о том, как они сохраняются. Шаблон репозитория изолирует домен от его сохранения.

Ответ 4

MVVM означает Model, View и ViewModel. Кусок, который вам не хватает, это модель, в которой живет ваш код доступа к данным.

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

class PersonModel : IPerson
{
    // data access stuff goes in here
    public string Name { get; set; }
}

class PersonViewModel
{
    IPerson _person;

    public PersonViewModel(IPerson person)
    {
        _person = person;
    }

    public Name
    {
        get { return _person.Name; }
        set { _person.Name = value; }
    }
 }

PersonView затем привязывался бы к свойствам PersonViewModel, а не непосредственно к самой модели. Во многих случаях у вас может уже быть уровень доступа к данным, который ничего не знает о MVVM (и не должен), но вы все равно можете создавать ViewModels, чтобы представить его в представлении.

Ответ 5

WPF Application Framework (WAF) содержит пример приложения, в котором показано, как Model-View-ViewModel (MVVM) может использоваться в комбинации с Entity Framework.

Ответ 6

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