Шаблон репозитория с Entity Framework 3.5 и MVVM. Должен ли я использовать один и тот же контекст везде?

Question

Я разрабатываю Файловую систему базы данных . Я использую -

1. .Net Framework 3.5
2. Entity Framework 3.5
3. WPF с рисунком MVVM

Проект охватывает несколько сборок, каждая из которых использует одну и ту же модель.

Одна сборка, назовем это «сервером», только добавляет данные в базу данных с использованием EF, т.е. той же модели. Другие сборки (включая пользовательский интерфейс) считывают и записывают данные. Изменения, сделанные сервером, должны немедленно отражаться в других сборки.

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

Я уже читал об этом в Code Project . Он везде использует один и тот же контекст (сущности).

У меня вопрос: должен ли я использовать один и тот же контекст везде? Каковы преимущества и недостатки этого?

Answer 1

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

Может быть, это то, что вы ищете.

Answer 2

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

Насколько ваш вопрос о сущностях, отражающих изменения в "сборках". Дело в том, что ваши объекты не живут, существуют в сборках. Они существуют в памяти.

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

Недостатком сохранения единого контекста является то, что каждый раз, когда вы выполняете запросы к контексту объекта, он увеличивается с сущностями, загруженными из БД. В долго работающем приложении это приводит к большому потреблению памяти.

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