Подходят ли когда-нибудь несколько классов DataContext?
-
08-06-2019 - |
Вопрос
Чтобы в полной мере использовать LinqToSql в приложении ASP.net 3.5, необходимо создать DataContext - текст данных классы (что обычно делается с помощью конструктора в VS 2008).С точки зрения пользовательского интерфейса, DataContext - это дизайн разделов вашей базы данных, доступ к которым вы хотели бы получить через LinqToSql, и является неотъемлемой частью настройки функций ORM LinqToSql.
Мой вопрос заключается в следующем:Я настраиваю проект, который использует большую базу данных, где все таблицы каким-то образом связаны между собой с помощью внешних ключей.Мое первое желание - создать один огромный класс DataContext, который моделирует всю базу данных.Таким образом, я мог бы теоретически (хотя я не знаю, понадобится ли это на практике) использовать соединения с внешним ключом, которые генерируются через LinqToSql, чтобы легко перемещаться между связанными объектами в моем коде, вставлять связанные объекты и т.д.
Однако, немного подумав, я теперь думаю, что, возможно, имеет смысл создать несколько классов DataContext, каждый из которых относится к определенному пространству имен или логически взаимосвязанному разделу в моей базе данных.Моя главная проблема заключается в том, что постоянное создание экземпляра и удаление одного огромного класса DataContext для отдельных операций, которые относятся к определенным областям базы данных, было бы ненужным наложением на ресурсы приложения.Кроме того, легче создавать небольшие файлы DataContext и управлять ими, чем одним большим файлом.Единственное, что я бы потерял, так это то, что были бы некоторые удаленные разделы базы данных, которые не были бы доступны для навигации через LinqToSql (даже если цепочка связей соединяет их в реальной базе данных).Кроме того, было бы несколько табличных классов, которые существовали бы более чем в одном DataContext.
Любые мысли или опыт относительно того, подходят ли несколько DataContexts (соответствующих пространствам имен БД) вместо (или в дополнение к) одному очень большому классу DataContext (соответствующему всей БД)?
Решение
Я не согласен с ответом Джона.DataContext (или Linq to Entities ObjectContext) - это скорее "единица работы", чем соединение.Он управляет отслеживанием изменений и т.д.Смотрите описание в этом блоге:
Время жизни LINQ для SQL DataContext
Четыре основных момента этого поста в блоге заключаются в том, что DataContext:
- Идеально подходит для подхода, основанного на "единице работы"
- Также предназначен для работы сервера без состояния
- Не предназначен для Длительного использования
Should be used very carefully after any SumbitChanges() operation.
Учитывая это, я не думаю, что использование более одного DataContext принесет какой-либо вред - фактически, создание разных DataContexts для разных типов работы помогло бы сделать вашу реализацию LinqToSql более удобной и организованной.Единственным недостатком является то, что вы не сможете использовать sqlmetal для автоматической генерации вашего dmbl.
Другие советы
Я спорил над тем же вопросом, пока заново устанавливал LINQ на SQL поверх устаревшей базы данных.Наша база данных довольно обширна (150 таблиц), и после некоторых размышлений и экспериментов я решил использовать несколько DataContexts.Считается ли это антишаблоном, еще предстоит выяснить, но на данный момент это делает жизнь управляемой.
Я думаю, Джон прав.
"Моя главная проблема заключается в том, что постоянное создание экземпляра и удаление одного огромного класса DataContext для отдельных операций, которые относятся к определенным областям базы данных, было бы ненужным наложением на ресурсы приложения"
Как вы поддерживаете это заявление?Каков ваш эксперимент, который показывает, что большой DataContext является узким местом в производительности?Наличие нескольких datacontexts во многом похоже на наличие нескольких баз данных и имеет смысл в аналогичных сценариях, то есть практически никогда.Если вы работаете с несколькими datacontexts, вам необходимо отслеживать, какие объекты какому datacontext принадлежат, и вы не можете связать объекты, которые не находятся в одном контексте данных.Это дорогостоящий дизайнерский запах без какой-либо реальной пользы.
@Evan "DataContext (или Linq to Entities ObjectContext) - это скорее "единица работы", чем соединение" Именно поэтому у вас не должно быть более одного datacontext.Зачем вам нужно больше одной "единицы работы" за раз?
Я вынужден не согласиться с общепринятым ответом.В поставленном вопросе система имеет единую большую базу данных с сильными связями по внешнему ключу почти между каждой таблицей (также случай, когда я работаю).В этом сценарии разбиение его на более мелкие DataContexts (DC) имеет два непосредственных и основных недостатка (оба упомянуты в вопросе):
- Вы теряете связи между некоторыми таблицами. Вы можете попытаться разумно выбрать границы своего DC, но в конечном итоге вы столкнетесь с ситуацией, когда было бы очень удобно использовать связь между таблицей в одном DC и таблицей в другом, но вы не сможете этого сделать.
- Некоторые таблицы могут отображаться в нескольких DC. Это означает, что если вы хотите добавить зависящие от таблицы вспомогательные методы, бизнес-логику или другой код в частичные классы, типы не будут совместимы между DC.Вы можете обойти это, унаследовав каждый класс сущностей от его собственного базового класса, что приводит к беспорядку.Кроме того, изменения схемы должны быть продублированы в нескольких контроллерах домена.
Теперь это существенные недостатки.Есть ли преимущества, достаточно большие, чтобы преодолеть их?В вопросе упоминается производительность:
Моя главная проблема заключается в том, что постоянное создание экземпляра и удаление одного огромного класса DataContext для отдельных операций, которые относятся к определенным областям базы данных, было бы ненужным наложением на ресурсы приложения.
На самом деле, это неправда, что большому DC требуется значительно больше времени для создания экземпляра или использования в типичной единице работы.На самом деле, после создания первого экземпляра в запущенном процессе последующие копии того же домена могут быть созданы практически мгновенно.
Единственное реальное преимущество нескольких контроллеров домена для единой большой базы данных с тщательными связями внешних ключей заключается в том, что вы можете немного лучше разделить свой код.Но вы уже можете сделать это с помощью частичных классов.
Кроме того, концепция единицы работы на самом деле не имеет отношения к первоначальному вопросу.Единица измерения работы обычно относится к объему работы одного постоянного тока. экземпляр выполняет, а не сколько работает постоянный ток класс является способный от делания.
По моему опыту работы с LINQ to SQL и LINQ to Entities DataContext является синонимом подключения к базе данных.Таким образом, если бы вы собирались использовать несколько хранилищ данных, вам нужно было бы использовать несколько DataContexts.Моя внутренняя реакция заключается в том, что вы не заметили бы значительного замедления работы с DataContext, который охватывает большое количество таблиц.Однако, если бы вы это сделали, вы всегда могли бы логически разделить базу данных в точках, где вы можете изолировать таблицы, которые не имеют никакого отношения к другим наборам таблиц, и создать несколько контекстов.