Comments 19
с таким кодом как минимум еще один недостаток — один юзер может легко смотреть файлы кеша другого
А как же быть с ViewState'ом?
По-моему данный подход годиться только для статических контролов и напоминает некоторое подобие шаблонов в PHP/Perl. Но их лучше кешировать уровнем IIS'а, да и сам ASP.NET умеет не плохо кешировать, т.ч. особого смысла я не заметила в решении.
По-моему данный подход годиться только для статических контролов и напоминает некоторое подобие шаблонов в PHP/Perl. Но их лучше кешировать уровнем IIS'а, да и сам ASP.NET умеет не плохо кешировать, т.ч. особого смысла я не заметила в решении.
ну может тут не совсем хорошо это реализовано, но так идея хорошая. Просто сам в одно время столкнулся с задачей, когда нужно было оптимизировать контролы. У меня их было не много, так что я в самих контролах все это реализовал. Но если много контроллов надо будет кешировать, то такая идея думаю подойдет.
Только добавил бы еще одну вещь как удаление кеша в зависимости от изменения данных(базы, файлов, времени и т.д.)
Только добавил бы еще одну вещь как удаление кеша в зависимости от изменения данных(базы, файлов, времени и т.д.)
Теоретически нельзя сделать 100% удалятор кэша
если например есть список товаров, разбитый по страницам, всего 10 страниц. Когда количество товаров уменьшается, то остаётся всего 5 страниц. И вот тут возникает проблемма, как удалить кэш от 6, 7, 8, 9, 10 страниц?
Даже если их срок действия истечёт, то файлы-то останутся.
Поэтому я и написал, что периодически это дело нужно целиком удалять, чтобы не оставалось лишних файлов.
если например есть список товаров, разбитый по страницам, всего 10 страниц. Когда количество товаров уменьшается, то остаётся всего 5 страниц. И вот тут возникает проблемма, как удалить кэш от 6, 7, 8, 9, 10 страниц?
Даже если их срок действия истечёт, то файлы-то останутся.
Поэтому я и написал, что периодически это дело нужно целиком удалять, чтобы не оставалось лишних файлов.
Я в самом начале написал, почему нельзя использовать стандартное кэширование.
По поводу ViewState: Содержимое кэшируемых контролов не предполагает наличия форм, а где нет форм вьюстэйт вообще не нужен и может быть отключен, т.е. никакой разницы нет
По поводу ViewState: Содержимое кэшируемых контролов не предполагает наличия форм, а где нет форм вьюстэйт вообще не нужен и может быть отключен, т.е. никакой разницы нет
Как-то это неправильно — перемешивать логику контрола и логику кеширования. Плюс сплошной хардкод.
Как решение, которое работает для вас — хорошо, поставил плюс, но как общий принцип — на мой взгляд, не очень удачно.
Как решение, которое работает для вас — хорошо, поставил плюс, но как общий принцип — на мой взгляд, не очень удачно.
Зато никакого гемороя: о)
«Геммороя» нет, пока проектом занимаетесь лично вы, а сам проект — небольшой.
Еще — я почему-то не уверен, что доступ к файлу будет быстрее, чем рендер контрола. Попробуйте меня переубедить )
Еще — я почему-то не уверен, что доступ к файлу будет быстрее, чем рендер контрола. Попробуйте меня переубедить )
При рендеренге из файла не обрабатываются события контролов, не происходит обращение к базе даных, меньше становится дерево контролов.
Вообще я замерял, разница существенная. (но зависит от контрола)
К тому же по поводу «перемешивать логику контрола и логику кеширования», наоборот, логика тут вынесена в базовый контрол, а в самом контроле идёт только реализация двух методов, Не многим сложнее, чем добавить директиву <% @OutputCache %>
Вообще я замерял, разница существенная. (но зависит от контрола)
К тому же по поводу «перемешивать логику контрола и логику кеширования», наоборот, логика тут вынесена в базовый контрол, а в самом контроле идёт только реализация двух методов, Не многим сложнее, чем добавить директиву <% @OutputCache %>
>> не обрабатываются события контролов
Не думаю, что это значительно влияет на производительность
>> не происходит обращение к базе даных
Имхо это плохо спроектированные контролы, если они ходят в БД, а не в кэш данных.
>>логика тут вынесена в базовый контрол
Я не про сложность добавления. Именно поэтому смешивается логика и данные: реализация двух методов заставляет каждый ваш контрол знать про кэш, про файлы и все остальное.
Вдобавок, своим решением вы сами себе поставили еще одну проблему — проблему очистки кеша. Она не сложная, однако — «нет кэш-файлов, нет проблем» )
Собстно, я не «наезжаю», просто хочу сказать, что в крупном проекте наличие такого решения, как ваше — борьба со следствием «тормозов» сайта, а не причиной; костыли для архитектуры, так сказать.
Не думаю, что это значительно влияет на производительность
>> не происходит обращение к базе даных
Имхо это плохо спроектированные контролы, если они ходят в БД, а не в кэш данных.
>>логика тут вынесена в базовый контрол
Я не про сложность добавления. Именно поэтому смешивается логика и данные: реализация двух методов заставляет каждый ваш контрол знать про кэш, про файлы и все остальное.
Вдобавок, своим решением вы сами себе поставили еще одну проблему — проблему очистки кеша. Она не сложная, однако — «нет кэш-файлов, нет проблем» )
Собстно, я не «наезжаю», просто хочу сказать, что в крупном проекте наличие такого решения, как ваше — борьба со следствием «тормозов» сайта, а не причиной; костыли для архитектуры, так сказать.
как вариант — просто не обновлять web.config, а заменять измененные файлы. иначе логика обновления портится — обновили много чего — значит нужно и кэш сбросить…
А если измененный файл — web.config? )
Кроме того, для precompiled app заменяй-не заменяй, приложение не отреагирует, если не перезагрузить домен приложения (например, обновлением web.config), а при выгрузке домена — свалится output кэш.
Для не-precompiled перезапись файла исходника также вызовет перезагрузку домена приложения — кэш теряется.
Кроме того, для precompiled app заменяй-не заменяй, приложение не отреагирует, если не перезагрузить домен приложения (например, обновлением web.config), а при выгрузке домена — свалится output кэш.
Для не-precompiled перезапись файла исходника также вызовет перезагрузку домена приложения — кэш теряется.
странно. меняю не-precompiled файлики — общий кэш не падает. (Cache)
у прекомпилед — нужно менять 2 фала — dll и файлик-указатель
у прекомпилед — нужно менять 2 фала — dll и файлик-указатель
Кэш обновляется, если изменяются файлы, от которых он зависит.
считается, что любой файл зависит от web.config
считается, что любой файл зависит от web.config
А у меня (в не-прекомпилед) кэш слетает, стоит только поменять файлик кешируемого контрола (.ascx), как и ожидалось. Что я делаю не так?
Sign up to leave a comment.
Альтернативный способ кэширования UserControl`ов в Asp.net