LINQ to SQL несколько DataContext-s

Я пытаюсь определить лучшую стратегию организации DataContexts. Типичный DB, который мы работаем, имеет от 50 до 100 таблиц, обычно в третьей нормальной форме и со многими отношениями между ними. Я думаю, у нас есть два варианта:

Поместите все таблицы в один контекст. Это гарантирует, что все, что мы делаем, будет выполнено в правильном порядке в базе данных. Проблема в том, что дизайнер LINQ будет бесполезным с более 50 таблицами, и я могу беспокоиться о производительности, которая может быть затронута.
Создайте несколько контекстов данных на основе логической группировки таблиц. Проблема в том, что будут места, где одна сторона отношения будет в одном контексте, а другая в другом. Мы должны вручную позаботиться о том, чтобы зафиксировать оба контекста в правильном порядке.

Есть ли рекомендуемая практика для этого?

Подробнее:

Я хочу создать свои собственные сущности и блок работы поверх LINQ to SQL. Объекты будут определены в файле модели xml, где также будет указано соответствие объектам LINQ. Пользовательский инструмент будет генерировать мои объекты (POCO) на основе модели. Клиентский код будет взаимодействовать только с моими сущностями и моей единицей работы; никогда напрямую с объектами DataContext или LINQ. Однако я не хочу дублировать то, что LINQ to SQL предоставляет из коробки, поэтому я хочу использовать базовый LINQ DataContext. Это означает, что у меня не может быть двух порядков в разных контекстах данных, так как было бы невозможно сопоставить мой порядок POCO с обоими из них.

Ответ 1

Это общий вопрос, который был тщательно проанализирован здесь: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

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

Ответ 2

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

Итак, возможно, у вас есть таблицы клиентов, адреса, телефона и т.д., с которыми вы имеете дело при отправке нового каталога. Затем у вас есть таблицы счетов, позиций, продуктов и т.д., Которые вы используете при создании заказа. Но в этом последнем наборе вы также можете иметь Клиента. Это здорово. Вы должны просто следить за тем, чтобы один сеанс активен одновременно, чтобы вы не использовали несогласованные данные. У вас не должно быть проблем с перекрывающимися объектами в ваших различных DataContexts, если вы не используете их с перекрытием.

Что касается беспорядка, вы можете поместить свой DataContext в конкретное пространство имен, и вы также можете поместить ваши различные объекты в определенное пространство имен (хотя бы одно пространство имен для каждого набора объектов в DataContext). Вы можете сделать это в окне "Свойства". Это позволит вам держать Intellisense менее беспорядочным.

Ответ 3

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

Контекст1: у Клиента много счетов-фактур

Контекст2: у Клиента много ордеров

Контекст3: Счет имеет много ордеров

Ответ 4

Я использую один datacontext для каждой базы данных.

Средние таблицы могут быть до 100, однако из опыта я не испытываю проблем с производительностью.

Datacontext находится в отдельном проекте, который компилируется. Результирующая dll, ссылающаяся на BLL