Entity Framework DataContexts

Question

Я борюсь с дизайном и пытаюсь найти лучший способ приблизиться к нему.

У нас много таблиц, и в текущей реализации LinqToSql наш DBML имеет много мегабайт, очень громоздкий.Я хочу избежать воссоздания этой ситуации, если смогу.Мы определяем нашу строку подключения для каждого пользователя, поэтому очень сложно создать отдельные базы данных для разных групп таблиц.

Я настроен на использование Entity Framework, и хотя нам не нужен кодВо-первых, мне нравится легкий код без генерации, и нам не нужно визуальное отображение, поэтому я подумал о том, чтобы сгенерировать файлы кода для всех таблиц, а затем добавить их в DataContext как DbSets.

Это заставило меня задуматься о наилучшей практике здесь, и я хотел задать вопрос;

Разумно ли создавать DataContext для каждой группы таблиц, которые вы хотите использовать.Т.е. у меня будет модуль, он будет отвечать за сбор данных из 5 таблиц, ему не нужны все таблицы в базе данных, только 5. Я создаю DbContext, который включает эти 5 таблиц.Если мне нужно больше в будущем, я могу добавить их, но это легко.

Answer 1

В большой модели DBML нет ничего плохого, влияние EF на производительность должно быть незначительным.

С другой стороны, на мой взгляд, уменьшение сложности также применимо к Entity Framework - если вашему коду требуется только 5Таблицы из базы данных непременно создают отдельный контекст, в котором есть только сущности для этих 5 таблиц.Выделяя полностью независимые таблицы в отдельные контексты, вы четко выражаете это разделение - нет никаких зависимостей от этих таблиц от других таблиц в вашей базе данных, и нет никаких зависимостей от кода для несвязанных сущностей - если это так, я думаю (и могут быть и другие мнения) это путь.

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

Answer 2

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

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

Одна вещь, которую я хотел бы прояснить, хотя. Я не обязательно предлагаю вам использовать конкретную сквозную архитектуру (то есть DDD). Здесь я пытаюсь предложить несколько шаблонов, которые дадут вам гибкость, позволяющую вам делать ошибки (изящно терпеть неудачу), продолжая при этом продвигаться в вашем проекте.

Answer 3

Вы, конечно, можете сделать это. Вы просто добавляете таблицы в модель edmx так же, как в Linq2SQL, поэтому, просто добавив 5 необходимых таблиц, вы сэкономите на дополнительных издержках на отслеживание сущностей для других неотслеживаемых таблиц. Entity Framework прекрасно добавляет двухсторонние свойства навигации, которых у Linq2SQL тоже нет. Я бы рекомендовал использовать EF вместо Linq2SQL.