Начало работы с промежуточным программным обеспечением Django, сеансами и кешированием

Question

Каждый пользователь в приложении Django связан с отделом, и практически каждый запрос связан с обработкой, связанной с отделом. Поэтому я хотел бы сделать объект отдела доступным во всем приложении.

Какой из них, если таковые имеются, является наиболее подходящим подходом принять:

1. Пользовательские промежуточного слоя, который просто получает связанную отдел из БД и присоединяет его к request объекта, скажем, как request.department, вроде например, AuthenticationMiddleware Django делает пользователя в настоящий момент доступным по адресу request.user. (См., Например, here10)
2. Размещение отдела в сеансе при входе пользователя в систему и последующем извлечении его во взглядах с использованием интерфейса request.session Django.

У меня еще не было возможности познакомиться с функциями кэширования Django, но я хотел бы, в конечном итоге, кэшировать отдел для каждого пользователя, чтобы избежать дополнительного попадания БД в каждый запрос. Я вижу это Django's sessions provide built-in caching support. Я также предполагаю, что кэширование может быть реализовано с помощью первого подхода.

Есть ли преимущество в использовании сеансов (# 2 выше) по сравнению с обычным промежуточным программным обеспечением (№ 1 выше) для такого рода вещей? Подход промежуточного программного обеспечения кажется более понятным с точки зрения внутреннего API, но я предполагаю, что это именно то, для чего предназначены сеансы, - возможно, это подходящая возможность начать их использовать?

Спасибо за любые рекомендации!

Answer 1

В принципе оба подхода очень похожи. request.session подход может просто устранить дополнительный шаг с настройкой кэширования в промежуточном программном обеспечении вручную. Плохое отношение к сеансовому подходу заключается в том, что данные не гарантируются, если вы используете кеш-память из коробки. Например, может быть 0,1% пользователей с отключенными куки-файлами, вы используете хранилище memcache, может возникнуть необходимость перезапустить сервер memcache при повторном развертывании, и ваши зарегистрированные пользователи потеряют свои данные и т. Д. Таким образом, я бы не стал использовать сеансы с кеш-памятью для важных данных. В моих проектах я предпочитаю использовать 1-й вариант, поскольку он дает мне больший уровень контроля.

Вы можете настроить имеют специальное ПО промежуточного слоя, добавив view_name переменную в запросе и позволяет контролировать, где и что показать:

class NameMiddleware(object): 
    def process_view(self, request, view_func, view_args, view_kwargs): 
     # add current view 
     if isinstance(view_func, str): 
      request.view_name = view_func 
     elif hasattr(view_func, '__name__'): 
      request.view_name = view_func.__name__ 

Тогда вы будете иметь больший контроль над где предоставить дополнительную информацию в запрос, например, в context_processors вы можете прикрепить отдел инфа только к выбранному виду и кэшировать результат эффективным способа (proxing запроса к базе данных, если вы хотите):

def department_context_processor(request): 
    if hasattr(request, 'view_name'): 
     if request.view_name == 'department_view1' or request.view_name == 'department_view2': 
      departments = cache.get('department_'+str(request.user), None) 
      if departments is None: 
       departments = Department.objects.filter(user=request.user) 
       cache.set('department_'+str(request.user), departments, 60*60) 
      if departments: 
       return { 
        'departments': departments 
       } 
    return {}