My<cod/>.net
Подходят ли когда-нибудь несколько классов DataContext?
Чтобы полностью использовать LinqToSql в приложении ASP.net 3.5, необходимо создать классы DataContext (что обычно делается с помощью конструктора в VS 2008). С точки зрения UI, DataContext-это дизайн разделов вашей базы данных, которые вы хотели бы предоставить через LinqToSql, и является неотъемлемой частью в настройке функций ORM LinqToSql.
Мой вопрос: я настраиваю проект, который использует большую базу данных, где все таблицы связаны каким-то образом через внешние ключи. Моя первая склонность-сделать один огромный класс DataContext, который моделирует всю базу данных. Таким образом, я мог бы теоретически (хотя я не знаю, понадобится ли это на практике) использовать внешние ключевые соединения, которые генерируются через LinqToSql, чтобы легко переходить между связанными объектами в моем коде, вставлять связанные объекты и т. д.
Однако после некоторых размышлений я теперь думаю, что может быть более целесообразно создать несколько классов DataContext, каждый из которых относится к определенному пространству имен или логическому взаимосвязанному разделу в моей базе данных. Моя главная проблема заключается в том, что создание и удаление одного огромного класса DataContext все время для отдельных операций, связанных с конкретными областями базы данных, будет налагать ненужное наложение на ресурсы приложения. Кроме того, легче создавать и управлять меньшими файлами DataContext, чем одним большим. То, что я потеряю, - это то, что будут некоторые удаленные разделы базы данных, которые не будут доступны для навигации через LinqToSql (даже если цепочка отношений соединяет их в реальной базе данных). Кроме того, будут существовать некоторые классы таблиц, которые будут существовать в более чем одном DataContext.
Любые мысли или опыт о том, являются ли множественные DataContexts (соответствующие пространствам имен DB) подходящими вместо (или в дополнение к) одному очень большому классу DataContext (соответствующему всему DB)?
Я не согласен с ответом Джона. DataContext (или Linq для сущностей ObjectContext) - это скорее "unit of work", чем соединение. Он управляет отслеживанием изменений и т. д. Смотрите это сообщение в блоге для описания:
Время жизни от LINQ до SQL DataContext
Четыре основных момента этого сообщения в блоге заключаются в том, что DataContext:
- Идеально подходит для подхода "unit of work"
- Также предназначен для "stateless" работа сервера
- Не предназначен для Долговечное использование
Should be used very carefully after any SumbitChanges() operation.
Учитывая это, я не думаю, что использование более чем одного DataContext принесет какой - либо вред-на самом деле, создание различных DataContexts для разных типов работы поможет сделать вашу LinqToSql импелментацию более удобной и организованной. Единственным недостатком является то, что вы не сможете использовать sqlmetal для автоматической генерации вашего dmbl.
Я спорил над тем же самым вопросом, пока ретро подгонял LINQ к SQL по наследству DB. Наша база данных немного громадна (150 таблиц), и после некоторых размышлений и экспериментов я решил использовать несколько DataContexts. Считается ли это анти-паттерном, еще предстоит выяснить, но пока это делает жизнь управляемой.
Я думаю, что Джон является правильным.
"Моя главная забота заключается в том, что создание экземпляра и размещение одного огромного класса DataContext все время для отдельных операций, которые относятся к конкретным областям базы данных, было бы ненужным наложением на ресурсы приложения"
Как вы поддерживаете это заявление? Каков ваш эксперимент, который показывает, что большой DataContext является узким местом производительности? Наличие нескольких datacontexts очень похоже на наличие нескольких баз данных и имеет смысл в подобных сценариях, то есть практически никогда. Если вы работаете с несколькими datacontexts, вам нужно отслеживать, какие объекты принадлежат к какому datacontext, и вы не можете связать объекты, которые не находятся в одном контексте данных. Это дорогостоящий дизайн, который не приносит никакой реальной пользы.
@Evan "DataContext (или Linq для сущностей ObjectContext) - это скорее "unit of work", чем соединение" Именно поэтому у вас не должно быть более одного datacontext. Почему вы хотите больше, чем один "unit of work" за раз?
Я должен не согласиться с принятым ответом. В поставленном вопросе система имеет одну большую базу данных с сильными отношениями внешнего ключа между почти каждой таблицей (также случай, когда я работаю). В этом сценарии разбиение его на меньшие DataContexts (DC) имеет два непосредственных и основных недостатка (оба упомянуты в вопросе):
- Вы теряете связи между некоторыми таблицами. Вы можете попытаться выбрать свои границы DC мудро, но в конечном итоге вы столкнетесь с ситуацией, когда было бы очень удобно использовать отношение из таблицы в одном DC к таблице в другом, и вы не сможете.
- Некоторые таблицы могут отображаться в нескольких классах DC. это означает, что если вы хотите добавить вспомогательные методы для таблиц, бизнес-логику или другой код в разделяемые классы, типы не будут совместимы между DC. Вы можете обойти это путем наследования каждого класса сущностей от своего собственного базового класса, который становится грязным. Кроме того, изменения схемы должны быть продублированы через несколько DC.
Теперь это существенные недостатки. Есть ли преимущества, достаточно большие, чтобы преодолеть их? Вопрос касается производительности:
Моя главная забота заключается в том, что создание и удаление одного огромного DataContext класс все время для отдельных операций, которые относятся к конкретным областям базы данных будет накладываться ненужное наложение на ресурсы приложения.
На самом деле, неверно, что большой DC занимает значительно больше времени для создания экземпляра или использования в типичной единице работы. Фактически, после того, как первый экземпляр создается в запущенном процессе, последующие копии того же DC могут быть созданы почти мгновенно .
Единственное реальное преимущество от нескольких DC для одной большой базы данных с тщательными отношениями внешнего ключа заключается в том, что вы можете немного лучше разделить свой код. Но вы уже можете сделать это с частичными классами.
Кроме того, концепция единицы работы на самом деле не имеет отношения к исходному вопросу. Единица работы обычно относится к тому, сколько работы выполняет один экземпляр DC, а не к тому, сколько работы способен выполнить класс DC.
В моем опыте с LINQ до SQL и LINQ до сущностей a DataContext является синонимом подключения к базе данных. Поэтому, если вы хотите использовать несколько хранилищ данных, вам нужно будет использовать несколько DataContexts. Моя внутренняя реакция заключается в том, что вы не заметите большого замедления с DataContext, который охватывает большое количество таблиц. Однако если бы вы это сделали, вы всегда могли бы логически разделить базу данных в точках, где вы можете изолировать таблицы, которые не имеют никакого отношения к другим наборам таблиц, и создать несколько контекстов.