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

Here's how I've been organizing my MVVM w/ LINQ projects:

Model - I think of the Model as the state of the system. It provides an interface to the data, and it keeps track of system status. The Model does not know about the ViewModel or View--it just provides a public interface to its data and various events to let the consumers (usually ViewModels) know when the state has changed.

ViewModel - The ViewModel is in charge of organizing or structuring all the data needed by the View, keeping track of the status of the view (such as the currently selected row of a data grid), and responding to actions on the view (such as button pushes). It knows what the view needs, but it doesn't actually know about the view.

View - The View is the actual look and feel of the UI. It contains all the built-in and custom controls, how they arranged, and how they are styled. It knows about the ViewModel, but only for the purpose of binding to its properties.

Gateway - This is the part that directly addresses your question. The Gateway (which is basically my way of saying "DataAccessLayer") is its own separate layer. It contains all the code (including LINQ queries) to CRUD or select, insert, update, and delete data from/to your data source (database, XML file, etc.). It also provides a public interface to the Model, allowing the Model to focus on maintaining system state without having to concern itself with the details (i.e., the queries) needed to update the data source.

DataAccess Classes - In C#, these are very simple classes that model your elemental data objects. When you select something using a LINQ query, you will usually create an IEnumerable or List where T is one of your data objects. An example of a data object would be:

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

The big advantage of a design like this is that it really separates your concerns. Everything has a specialized job, and it's (usually) pretty easy to know what kind of thing goes where.

The disadvantage is that it may be overkill for small projects. You end up creating a lot of infrastructure for public interfaces that basically pass a single wish through several layers. So, you might end up with a scenario like this: [user clicks Submit, ViewModel tells Model to AddNewPerson, Model tells Gateway to InsertPerson] instead of a scenario like this [user clicks Submit, ViewModel adds new record to the database directly].

Hope that helps.

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

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

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

MVVM означает Модель , Представление и Модель представления . Вам не хватает модели, в которой живет ваш код доступа к данным.

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

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 (и не должен), но вы все равно можете создавать модели представления, чтобы представить их представлению.

Your ViewModel should be a thin layer that just services the view. My rule of thumb: if it has to do with the presentation of the UI, then it belongs in the ViewModel, otherwise it should be in the Model.

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