Предварительная выборка данных с использованием Linq-to-SQL, IOC и репозитория - PullRequest
Новая
       38

Предварительная выборка данных с использованием Linq-to-SQL, IOC и репозитория

3 голосов
/ 23 октября 2009

с использованием Linq-to-SQL Я хотел бы предварительно извлечь некоторые данные.

1) общее решение состоит в том, чтобы иметь дело с DataLoadOptions , но в моей архитектуре это не будет работать, потому что:

  • опции должны быть установлены до первого запроса
  • Я использую IOC, поэтому я не создаю экземпляр DataContext напрямую (я не могу выполнить код при создании экземпляра)
  • мой DataContext является постоянным в течение веб-запроса

2) Я видел еще одну возможность, основанную на загрузке данных и их дочерних элементов в методе, а затем возвращении только данных (таким образом, дочерний элемент уже загружен) см. пример здесь

Тем не менее, в моей архитектуре это не может не работать:

  • Мои запросы каскадно выходят из моего репозитория и могут использоваться многими службами, которые будут добавлять пункты
  • Я работаю с интерфейсами, конкретные экземпляры объектов linq-to-sql не покидают репозитории (да, вы можете работать с интерфейсами И добавлять предложения)
  • Мои репозитории являются общими

Да, эта архитектура довольно сложна, но она очень крутая, так как я могу играть с кодом, похожим на lego;)

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

Ответы [ 3 ]

1 голос
/ 08 ноября 2009

В моем приложении я использую, возможно, вариант вашего потенциального решения # 2. Это довольно сложно объяснить, но просто: я включаю и откладываю ленивую загрузку в моей модели с помощью пользовательских ленивых классов , чтобы абстрагироваться от дифференцированного выполнения, специфичного для LinqToSql, которым я пользуюсь с помощью IQueryable. Преимущества:

  • Моя модель домена и уровень сервиса вверх не обязательно должны зависеть от поставщика LinqToSql (я могу поменять свой DAL с интерфейсами, если я хочу)
  • Методы My Service могут и действительно возвращать полные графы объектов с несколькими «точками привязки» для отложенной загрузки, используя классы, которые абстрагируют конкретную реализацию отложенной загрузки - так что я могу использовать специфичное для LinqToSql дифференциальное выполнение или что-то еще (например, anon делегаты Снова, обратитесь к этот ответ )
  • Я могу сохранять результаты IQueryable во всем приложении (даже в интерфейсе, если я хочу), что позволяет бесконечно формировать цепочку запросов LINQ, не беспокоясь о производительности.
1 голос
/ 24 октября 2009

Я не знаю о других возможностях, похоже, вы выдвинули LinqToSql до его предела (однако, я могу ошибаться).

Я думаю, что ваши лучшие варианты на данный момент:

  1. Добавьте в приложение несколько «неуниверсальных» методов для обработки только конкретные сценарии, где вы хотите / нуждаетесь в стремительной загрузке и не используйте вашу "обычную", "общую" инфраструктуру для этих методов.
  2. Используйте ORM, который имеет более сложную поддержку для быстрой и ленивой загрузки.
0 голосов
/ 26 октября 2009

Я нашел решение. Мой ответ: « Внедрение зависимости ».

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

Все, что мне нужно, это ввести класс CustomDCParameter , когда я создаю DC. Этот класс будет содержать правила, и конструктор будет применять их все.

...