WPF и LINQ / SQL - как и где отслеживать изменения?

Question

У меня есть приложение WPF, созданное с использованием шаблона MVVM:

• Мои модели приходят из LINQ to SQL.
• Я использую шаблон репозитория для абстрагирования DataContext.
• Мои ViewModels имеют ссылку на модель.
• Установка свойства в ViewModel приводит к тому, что это значение записывается в модель.

Как видите, мои данные хранятся в моей модели, поэтому изменения отслеживаются моим DataContext.

Однако в этом вопросе Я прочитал:

Рекомендации MSDN документация по классу DataContext Вот что я бы порекомендовал следующее:

В общем случае экземпляр DataContext рассчитан на одну единицу работа "однако ваше приложение определяет этот термин. DataContext - это легкий и не дорогой Создайте. Типичный LINQ to SQL приложение создает DataContext экземпляры в области видимости метода или как член недолговечных классов, которые представляют собой логический набор связанных операции с базой данных.

Как вы отслеживаете свои изменения? В вашем DataContext? В вашей ViewModel? В другом месте?

Answer 1

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

Если вы полностью отключите DataContext от своей виртуальной машины, и они будут работать самостоятельно, ваше приложение станет:

• Гораздо более тестируемый - ваши виртуальные машины могут быть протестированы без datacontext
• Потенциально не сохраняя состояния на уровне данных - легко изменить вашу архитектуру для принятия 3-уровневого решения без сохранения состояния.
• Возможность простой интеграции других источников данных - ваши виртуальные машины могут элегантно содержать агрегаты и комбинации других источников данных самостоятельно.

Короче говоря, да, я бы рекомендовал отделить классы доступа к данным от объектов ViewModel во всем приложении. Это может быть немного больше кода, но это принесет дивиденды в будущем с гибкостью архитектуры.

РЕДАКТИРОВАТЬ: Я не использую функции отслеживания изменений объектов L2SQL после того, как они пересекли границу распределения. Это довольно быстро превращается в банку с червями - вы можете тратить много времени на заботу и подачу графов объектов вашей модели данных внутри вашей модели представления - что не только усложняет ViewModel, но, по крайней мере, транзитивно связывает ViewModel с схема базы данных. Вместо этого я делаю ViewModel чистым. Когда придет время их сохранения, ваш сервисный уровень / репозиторий / что угодно выполняет преобразование между ViewModel и объектами данных. Сначала это кажется большой работой, но для всего, кроме простого CRUD, этот дизайн окупается довольно быстро.

Answer 2

Как бы вы ни управляли данными внутри программы, экземпляры объектов сгенерированных классов L2SQL создаются как обычные объекты, без использования контекста данных. DataContext отвечает только за взаимодействие с базой данных.

Эти рекомендации могут означать, что вы можете делать что-либо с объектами сгенерированных L2SQL классов, но не оставляйте объект, который передает данные между ними и базой данных. Вы можете обращаться с классами L2SQL как с любыми другими классами, которые вы можете использовать по своему усмотрению, с дополнительной возможностью считывания и записи в базу данных.

Это предположение. Я не могу сказать, что было в голове MSDN автора этой волшебной фразы, но это объяснение имеет смысл. Сохраняйте данные в объектах сгенерированных классов L2SQL в течение всей деятельности программы и синхронизируйте их с базой данных с помощью временных объектов DataContext.