LINQ to SQL несколько DataContext-ов
Я пытаюсь придумать лучшую стратегию организации DataContexts. Типичная БД, с которой мы работаем, имеет от 50 до 100 таблиц, обычно в третьей нормальной форме и со множеством связей между ними. Думаю, у нас есть два варианта:
- Поместите все таблицы в единый контекст. Это гарантирует, что все, что мы делаем, будет зафиксировано в правильном порядке в базе данных. Проблема в том, что конструктор LINQ запутается с более чем 50 таблицами, и я опасаюсь, что это может повлиять на производительность.
- Создайте несколько контекстов данных на основе логической группировки таблиц. Проблема в том, что будут места, где одна сторона отношения будет находиться в одном контексте, а другая - в другом. Придется вручную позаботиться о фиксации обоих контекстов в правильном порядке.
Есть ли какая-либо рекомендуемая практика для решения этой проблемы?
Подробнее:
Я хочу создать свои собственные сущности и единицы работы поверх LINQ to SQL. Сущности будут определены в файле модели xml, где также будет указано сопоставление с сущностями LINQ. Пользовательский инструмент сгенерирует мои объекты (POCO) на основе модели. Клиентский код будет взаимодействовать только с моими сущностями и моей единицей работы; никогда напрямую с сущностями DataContext или LINQ. Однако я не хочу дублировать то, что LINQ to SQL предоставляет из коробки, поэтому я хочу использовать базовый LINQ DataContext. Это означает, что у меня не может быть двух заказов в разных контекстах данных, потому что невозможно сопоставить мой заказ POCO с обоими из них.
Ответы 4
Вы должны создать контексты, позволяющие выполнять единицы работы. Это может включать в себя перекрывающиеся сопоставления таблиц.
Контекст1: у клиента много счетов-фактур
Контекст2: у клиента много заказов
Context3: в счете-фактуре много заказов
Если работа разделена на единицы, вы никогда не попытаетесь использовать объект из context2 в context3.
На самом деле я хочу реализовать POCO и Unit of Work поверх сущностей LINQ, чтобы клиентский код работал с UnitOfWork, у которого будет только один тип заказов. В предложенном вами решении я бы не знал, какой контекст использовать для заказов
Если у вас есть только одна единица работы для заказов, вам, очевидно, не нужны два определения контекста для этой единицы работы.
Сопоставления LINQ-to-SQL похожи на типизированные наборы данных в том смысле, что при их использовании вы имеете дело с сеансом, содержащим данные. У вас могут быть одни и те же таблицы в нескольких разных DataContexts. В конце концов, они всего лишь классы; они ничего не значат, пока вы не начнете взаимодействовать с базой данных, заполняя их существующими данными или используя их для создания новых данных.
Так что, возможно, у вас есть таблицы «Клиент», «Адрес», «Телефон» и т. д., С которыми вы работаете при рассылке нового каталога. Затем у вас есть таблицы «Счет-фактура», «Статья затрат», «Продукт» и т. д., Которые вы используете при создании заказа. Но в этом последнем наборе вы также можете захотеть иметь Customer. Отлично. Вам следует просто позаботиться о том, чтобы одновременно был активен только один сеанс, чтобы не использовать несогласованные данные. У вас не должно возникнуть проблем с перекрытием сущности в ваших различных DataContexts, если вы не используете их перекрывающимся образом.
Что касается беспорядка, вы можете поместить свой DataContext в определенное пространство имен, а также можете поместить свои различные сущности в определенное пространство имен (хотя только одно пространство имен на набор сущностей в DataContext). Вы можете сделать это в окне «Свойства». Это позволит избежать путаницы с Intellisense.
Я использую один текст для каждой базы данных.
Средних таблиц может быть до 100, однако по опыту я не испытываю никаких проблем с производительностью.
Датаконтекст находится в отдельном проекте, который компилируется. Результирующая dll, на которую ссылается BLL
Это общий вопрос, который здесь подробно проанализирован: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/
По сути, вы должны создать не более одного контекста данных для каждой сильно связанной группы таблиц или одного контекста данных для каждой базы данных.
терминология здесь, означает ли это, что есть только один DataContext db = new DataContext (), происходящий внутри метода, который блокирует объект (или делает что-то, чтобы гарантировать, что только один сохраняется одновременно)?
Я думаю об этом, но заказ из Context2 не может использоваться в Context3 .... вы получите два разных объекта заказа