Есть несколько классов DataContext всегда уместно?

голоса
27

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

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

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

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

Задан 05/08/2008 в 06:54
источник пользователем
На других языках...                            


5 ответов

голоса
1

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

Ответил 05/08/2008 в 10:57
источник пользователем

голоса
4

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

Ответил 05/08/2008 в 23:51
источник пользователем

голоса
25

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

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

Четыре основные моменты этого блога в том, что DataContext:

  1. Идеально подходит для «единицу работы» подход
  2. Также предназначен для «без гражданства» работы сервера
  3. Не предназначен для долгоживущих использования
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

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

Ответил 07/08/2008 в 22:02
источник пользователем

голоса
3

Я думаю, что Джон является правильным.

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

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

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

Ответил 27/08/2008 в 02:11
источник пользователем

голоса
3

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

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

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

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

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

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

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

Ответил 17/06/2014 в 21:53
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more