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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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