Рекомендуемый шаблон для отложенной загрузки частей графов объектов из кэша

Question

Я использую memcache за веб-приложением, чтобы минимизировать попадания в нашу базу данных SQL.Я храню объекты C # в этом кеше, помечая их SerializableAttribute.Мы интенсивно используем внедрение зависимостей через Ninject в нашем приложении.

Некоторые из этих объектов большие, и я бы хотел их разбить.Тем не менее, они приходят из одного вызова хранимой процедуры (то есть один вызов хранимой процедуры готовится к полному графу объектов), и я хотел бы иметь возможность разбивать эти объекты и отдельно загружать определенные подграфы из кеша отдельнозагрузить весь граф объектов в память все сразу.

Какие шаблоны могут помочь мне в этом?

Answer 1

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

Шаблон, к которому я привык, является типом шаблона репозитория, в котором используются операции, выполняющие конкретные контракты. И эти операции содержат один или несколько источников данных, которые вызывают хранимые процедуры в базе данных, которые будут использоваться для построения ОДНОГО из тех подграфов, о которых вы говорите. С учетом вышесказанного, если вы собираетесь лениво загружать данные из базы данных, то я могу только предположить, что многие члены объекта не используются большую часть времени, что способствует моей точке зрения - разбить этот объект.

Пара вещей об этом:

• Это может быть болтливым, если весь объект используется регулярно
• Он полностью вводится через операции
• Источники данных содержат считыватель для конкретного объекта, таким образом, выполняя только ОДНУ задачу (SOLID)
• Может быть изменен для использования Entity Framework без особых хлопот
• Может быть разработан для реализации интерфейса, что делает его более пригодным для повторного использования
• Потребуется, чтобы вы разбили этот процесс на более мелкие жевательные кусочки, которые, скорее всего, принесут вам пользу только в долгосрочной перспективе.
• Сложный объект, показанный на этой диаграмме, действительно не должен существовать, если будут использоваться только его части. Вместо этого рассмотрите возможность разделения этих объектов. Однако это зависит от того, как этот объект используется.

UPDATE:

Используя ваш кеш в качестве репозитория, я, вероятно, подхожу к нему так:

Таким образом, в основном вы сохраняете устаревший объект, но в своих операциях вы используете их для создания более релевантных DTO, которые возвращаются клиенту.

Answer 2

Я знаю, что NHibernate делает ленивую загрузку, заменяя объекты прокси-объектами. Затем в прокси-объекте выполняется проверка, которая вызывает загрузку реального объекта при первом обращении к объекту.

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

Недостатком использования прокси-объектов является то, что вы должны быть осторожны с проверками наследования и типов, поскольку вы можете проверять тип прокси, а не фактический объект.