Должен ли я использовать один LINQ DataContext или несколько?

Question

Для большого проекта, имеет ли смысл иметь один текстовый текст, который отображает вашу базу данных, с которой вы можете взаимодействовать из ваших классов?

Или было бы более разумно разделить это на небольшие точки данных, которые ориентированы на конкретные задачи в базе данных, которые потребуются.

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

Я также думаю, что вы выиграете во время JIT, так как первый класс, который сделает доступ к данным, скомпилирует ваш dc, который теперь доступен для всех классов.

Answer 1

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

Хотя может быть возможно разделить вашу базу данных на несколько контекстов данных, это было бы желательно, если и только если между двумя контекстами было перекрытие нуля.

Наложение плохое

например. у вас есть WebsiteContext и AdminContext. WebsiteContext предназначен для отображения Product и выполнения Order с. WebsiteUser прикреплен к Order. AdminContext для ваших Staff участников, чтобы обработать возвраты за отмененный Orders, который также ссылается на WebsiteUser. AdminContext также необходимо сбросить пароли и обновить другие данные для WebsiteUser.

Вы думаете об этом, потому что не хотите, чтобы веб-сайт обрабатывал или даже не знал о Returns

WebsiteContext
Product -- Order -- WebsiteUser

AdminContext
Staff -- Returns -- Order -- WebsiteUser 

В приведенном выше примере мы видим, что дублируем множество объектов в разных контекстах данных. Это плохо пахнет, и это действительно указывает на то, что искусственное разделение базы данных на разные контексты данных является неправильным решением. В конце концов, у вас есть> 2 базы данных или только одна? Дублирование нарушает принцип СУХОГО (не повторяйте себя), потому что WebsiteContext.WebsiteUser отличается от AdminContext.WebsiteUser, и, по всей вероятности, код будет запутанным, когда что-то нужно заботиться о том, на который они ссылаются.

---

Linq Data Context - это просто OR OR, и его нужно рассматривать как причудливый черный ящик, который облегчает написание части кода доступа к данным. Некоторые демоверсии linq создают впечатление, что вам больше не нужны другие слои, но программа любой сложности по-прежнему выигрывает от многоуровневого дизайна.

Вам, вероятно, лучше рассматривать объекты Linq как просто объекты для простой передачи данных и создавать слой домена, который скрывает их как детали реализации. Прочитайте DDD - Дизайн, управляемый доменом.

Само по себе использование объектов Linq из пользовательского интерфейса больше всего напоминает шаблон Transaction Script. В таком случае вы все равно выиграете от наличия логического слоя, который позаботится о деталях.

---

Хотя вы не хотите, чтобы ответственность за контекст была настолько широкой, контекст данных - это просто представление базы данных. Это не механизм безопасности, и он не может помешать вам испортить данные.

Answer 2

С точки зрения «шаблона репозитория» можно сказать, что есть отдельные агрегаты и минимизируются навигационные свойства между агрегатами. Я не уверен на 100%, что это за что-то , хотя ... на данный момент я рассматриваю , используя dbml среднего размера, с несколькими хранилищами, использующими его не использовать Datacontexts напрямую - только классы репозитория), со свойствами навигации, помеченными как внутренние, чтобы DAL мог их использовать ... Может быть ...