Подходят ли когда-либо несколько классов DataContext?

По моему опыту работы с LINQ to SQL и LINQ to Entities, DataContext является синонимом подключения к базе данных. Поэтому, если вам нужно было использовать несколько хранилищ данных, вам нужно было бы использовать несколько DataContexts. Моя интуиция такова, что вы не заметите большого замедления работы с DataContext, охватывающим большое количество таблиц. Если бы вы это сделали, вы всегда могли бы логически разделить базу данных в точках, где вы можете изолировать таблицы, которые не имеют никакого отношения к другим наборам таблиц, и создать несколько контекстов.

Я спорил над тем же вопросом, когда настраивал LINQ to SQL поверх устаревшей БД. Наша база данных немного огромна (150 таблиц), и после некоторых размышлений и экспериментов я решил использовать несколько DataContexts. Будет ли это считаться антипаттерном, еще неизвестно, но пока это делает жизнь управляемой.

Я не согласен с ответом Джона. DataContext (или Linq to Entities ObjectContext) - это скорее «единица работы», чем соединение. Он управляет отслеживанием изменений и т. д. См. Описание в этом сообщении в блоге:

Время жизни LINQ to SQL DataContext

Четыре основных момента этого сообщения в блоге заключаются в том, что DataContext:

1. Идеально подходит для подхода "единицы работы"
2. Также предназначен для работа сервера "без сохранения состояния"
3. Не предназначен для Долгоживущее использование

4. Should be used very carefully after
   any SumbitChanges() operation.
   

Учитывая это, я не думаю, что использование более одного DataContext принесет какой-либо вред - на самом деле, создание разных DataContexts для разных типов работы поможет сделать ваше внедрение LinqToSql более удобным и организованным. Единственным недостатком является то, что вы не сможете использовать sqlmetal для автоматической генерации dmbl.

Я думаю, что Джон прав.

«Меня больше всего беспокоит то, что постоянное создание и удаление одного огромного класса DataContext для отдельных операций, относящихся к определенным областям базы данных, приведет к ненужному наложению на ресурсы приложения»

Как вы поддерживаете это утверждение? Какой ваш эксперимент показывает, что большой DataContext является узким местом производительности? Наличие нескольких текстов данных очень похоже на наличие нескольких баз данных и имеет смысл в аналогичных сценариях, то есть практически никогда. Если вы работаете с несколькими контекстами данных, вам необходимо отслеживать, какие объекты принадлежат какому тексту данных, и вы не можете связывать объекты, которые не находятся в одном контексте данных. Это дорогостоящий дизайнерский запах, не приносящий реальной пользы.

@Evan "DataContext (или Linq to Entities ObjectContext) - это скорее" единица работы ", чем соединение" Именно поэтому у вас не должно быть более одного контекста данных. Зачем вам нужно больше одной «единицы работы» за раз?

Я не согласен с принятым ответом. В заданном вопросе система имеет одну большую базу данных с сильными отношениями внешнего ключа почти между каждой таблицей (также в том случае, когда я работаю). В этом сценарии разбиение его на более мелкие DataContexts (DC) имеет два непосредственных и основных недостатка (оба упомянуты в вопросе):

1. Вы теряете связи между некоторыми таблицами. Вы можете попытаться выбрать границы своего DC с умом, но в конечном итоге вы столкнетесь с ситуацией, когда было бы очень удобно использовать связь из таблицы в одном DC к таблице в другом, и у вас не получится.
2. Некоторые таблицы могут отображаться в нескольких контроллерах домена. Это означает, что если вы хотите добавить специфичные для таблицы вспомогательные методы, бизнес-логику или другой код в частичные классы, эти типы не будут совместимы между DC. Вы можете обойти это, унаследовав каждый класс сущности от его собственного конкретного базового класса, что становится беспорядочным. Кроме того, изменения схемы необходимо будет продублировать на нескольких контроллерах домена.

Теперь это существенные недостатки. Есть ли достаточно большие преимущества, чтобы их преодолеть? В вопросе упоминается производительность:

My main concern is that instantiating and disposing one huge DataContext class all the time for individual operations that relate to specific areas of the Database would be impose an unnecessary imposition on application resources.

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

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

Кроме того, концепция единицы работы не имеет отношения к исходному вопросу. Единица работы обычно относится к тому, сколько работы выполняет один DC пример, а не к тому, сколько работы DC учебный класс выполняет способный.