Несколько классов 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 to 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

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

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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