asp.net - объект - производные классы с++




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

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

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

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

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


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


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

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

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

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


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


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

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

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

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

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

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

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





datacontext