Блог

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

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

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

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

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

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

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

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

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

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

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

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