LINQ to SQL несколько DataContext-ы - PullRequest
       9

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

11 голосов
/ 24 октября 2008

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

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

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

Подробнее:

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

Ответы [ 4 ]

4 голосов
/ 19 июля 2010

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

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

2 голосов
/ 24 октября 2008

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

Так что, возможно, у вас есть таблицы «Клиент», «Адрес», «Телефон» и т. Д., С которыми вы работаете при отправке нового каталога. Затем у вас есть таблицы Invoice, Line Item, Product и т. Д., Которые вы используете при создании заказа. Но в последнем наборе вы также можете захотеть иметь Заказчика. Все в порядке. Вам следует просто позаботиться о том, чтобы одновременно был активен только один сеанс, чтобы вы не использовали противоречивые данные. У вас не должно быть проблем с перекрытием сущностей в ваших различных DataContexts, если вы не используете их перекрывающимся способом.

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

0 голосов
/ 19 апреля 2009

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

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

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

0 голосов
/ 24 октября 2008

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

Context1: у клиента много счетов

Context2: у клиента много заказов

Context3: в счете много заказов

...