Подтвердить что ты не робот

Являются ли несколько классов DataContext подходящими?

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Срок службы LINQ to SQL DataContext

Четыре основных момента этого сообщения в блоге - DataContext:

  • Идеально подходит для подхода "единицы работы"
  • Также предназначен для Операция сервера без состояния
  • Не предназначен для   Долгосрочное использование
  • Should be used very carefully after
any SumbitChanges() operation.

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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