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

Question

Чтобы в полной мере использовать LinqToSql в приложении ASP.net 3.5, необходимо создать DataContext - текст данных классы (что обычно делается с помощью конструктора в VS 2008).С точки зрения пользовательского интерфейса, DataContext - это дизайн разделов вашей базы данных, доступ к которым вы хотели бы получить через LinqToSql, и является неотъемлемой частью настройки функций ORM LinqToSql.

Мой вопрос заключается в следующем:Я настраиваю проект, который использует большую базу данных, где все таблицы каким-то образом связаны между собой с помощью внешних ключей.Мое первое желание - создать один огромный класс DataContext, который моделирует всю базу данных.Таким образом, я мог бы теоретически (хотя я не знаю, понадобится ли это на практике) использовать соединения с внешним ключом, которые генерируются через LinqToSql, чтобы легко перемещаться между связанными объектами в моем коде, вставлять связанные объекты и т.д.

Однако, немного подумав, я теперь думаю, что, возможно, имеет смысл создать несколько классов DataContext, каждый из которых относится к определенному пространству имен или логически взаимосвязанному разделу в моей базе данных.Моя главная проблема заключается в том, что постоянное создание экземпляра и удаление одного огромного класса DataContext для отдельных операций, которые относятся к определенным областям базы данных, было бы ненужным наложением на ресурсы приложения.Кроме того, легче создавать небольшие файлы DataContext и управлять ими, чем одним большим файлом.Единственное, что я бы потерял, так это то, что были бы некоторые удаленные разделы базы данных, которые не были бы доступны для навигации через LinqToSql (даже если цепочка связей соединяет их в реальной базе данных).Кроме того, было бы несколько табличных классов, которые существовали бы более чем в одном DataContext.

Любые мысли или опыт относительно того, подходят ли несколько DataContexts (соответствующих пространствам имен БД) вместо (или в дополнение к) одному очень большому классу DataContext (соответствующему всей БД)?

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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