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

Question

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

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

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

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

Answer 1

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

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

Перекрытие это плохо

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

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

WebsiteContext 
Product -- Order -- WebsiteUser 

AdminContext 
Staff -- Returns -- Order -- WebsiteUser 

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

---

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

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

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

---

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

Answer 2

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