Постараюсь. Не совсем уверен, уместно ли это в комментах — по вашему желанию можем переместиться в личную переписку.
Кратко, enum — это перечисление заведомо известных констант, строковых, числовых или объектных. Как-то так:
public static class Proprtions {
public const string AUTO = «auto»;
public const string BY_HEIGHT = «height»;
public const string BY_WIDTH = «width»;
}
После чего в коде не нужно писать строки, а можно явно указывать, что вы имели в виду: например, Proportions.AUTO. Помимо избавления от синтаксических ошибок, это позволяет более логично писать код — например, ничто не мешает объявить еще одну константу DEFAULT и сделать ее равной AUTO. Код будет содержать больше логики, и меньше деталей реализации.
Про exceptions — советую почитать не только дискуссии на Хабре, но вам виднее.
Класс events вы не очень удачно назвали — стоит переименовать его в EventLog, например. Кроме того, так и не понял, зачем вам singleton.
Так же хотел узнать — php, кажется, поддерживает обработку исключений, но вы ее почему-то не используете.
Кроме того, стоит использовать enum или их аналоги вместо хардкодных строк-вариантов (например, в $proportion)
Я на PHP не писал, поэтому не могу адекватно оценить; посему у меня совершенно ламерский вопрос — а к Drupal'у затруднительно написать админку, в которой клиент мог бы разобраться?
>> В основном ставка у меня делалась не на архитектуру, а на удобство админки,
Что вы понимаете под архитектурой и почему у вас тут противопоставление? Разве первое не есть хороший фундамент для второго?
Вычисляет не клиент, а спец. ПО. Погуглите punkbuster — устанавливается сервисом в винду, и занимается проверкой на легальность и отсутствие ботов, читов и трейнеров. Причем эту штуку используют очень многие игры, т.к. она универсальна и с высокой долей вероятности «банит» ботоводов и проч. Если отключите сервис — не сможете законнектиться на сервер. Все просто.
Первая строка поста такова:
«Думаю все, кто использует Asp.net для разработки web-сайтов, прекрасно знают, что в Asp.net имеет встроенное кеширование UserControl`ов.»
Речь идет об output (fragment) cache. HttpContext.Current.Cache сюда не относится.
А если измененный файл — web.config? )
Кроме того, для precompiled app заменяй-не заменяй, приложение не отреагирует, если не перезагрузить домен приложения (например, обновлением web.config), а при выгрузке домена — свалится output кэш.
Для не-precompiled перезапись файла исходника также вызовет перезагрузку домена приложения — кэш теряется.
>> не обрабатываются события контролов
Не думаю, что это значительно влияет на производительность
>> не происходит обращение к базе даных
Имхо это плохо спроектированные контролы, если они ходят в БД, а не в кэш данных.
>>логика тут вынесена в базовый контрол
Я не про сложность добавления. Именно поэтому смешивается логика и данные: реализация двух методов заставляет каждый ваш контрол знать про кэш, про файлы и все остальное.
Вдобавок, своим решением вы сами себе поставили еще одну проблему — проблему очистки кеша. Она не сложная, однако — «нет кэш-файлов, нет проблем» )
Собстно, я не «наезжаю», просто хочу сказать, что в крупном проекте наличие такого решения, как ваше — борьба со следствием «тормозов» сайта, а не причиной; костыли для архитектуры, так сказать.
>> то теперь при возникновении критических ошибок QPI будет делать попытки их исправить на лету
А вы не в курсе, случайно, что это даст пользователям? Потому что имхо серьезные ошибки на шине связи — это нештатный режим однозначно, а в нем вряд ли кто-то планирует работать.
Любое действие рождает противодействие, а насилие — ответное насилие. Парень из статьи пока идет только самым гуманным путем, при помощи законов и общественного права. Но мне кажется, что если RIAA будет продолжать действовать таким образом, скоро найдется свой Марвин Химейер, который «вынесет» эту систему самым грубым образом.
И я что-то не увидел транзакции — ни в коде, ни в обсуждении. Интересно, как там дело с ACID?
Кратко, enum — это перечисление заведомо известных констант, строковых, числовых или объектных. Как-то так:
public static class Proprtions {
public const string AUTO = «auto»;
public const string BY_HEIGHT = «height»;
public const string BY_WIDTH = «width»;
}
После чего в коде не нужно писать строки, а можно явно указывать, что вы имели в виду: например, Proportions.AUTO. Помимо избавления от синтаксических ошибок, это позволяет более логично писать код — например, ничто не мешает объявить еще одну константу DEFAULT и сделать ее равной AUTO. Код будет содержать больше логики, и меньше деталей реализации.
Про exceptions — советую почитать не только дискуссии на Хабре, но вам виднее.
Класс events вы не очень удачно назвали — стоит переименовать его в EventLog, например. Кроме того, так и не понял, зачем вам singleton.
Строки
«if ($highest == 0) {
$this->e->add(6, 'highest:'. $highest. 'px');
return false;
}»
смущают. Зачем нужна склейка с заведомо известным $highest == 0?
Так же хотел узнать — php, кажется, поддерживает обработку исключений, но вы ее почему-то не используете.
Кроме того, стоит использовать enum или их аналоги вместо хардкодных строк-вариантов (например, в $proportion)
Что вы понимаете под архитектурой и почему у вас тут противопоставление? Разве первое не есть хороший фундамент для второго?
«Думаю все, кто использует Asp.net для разработки web-сайтов, прекрасно знают, что в Asp.net имеет встроенное кеширование UserControl`ов.»
Речь идет об output (fragment) cache. HttpContext.Current.Cache сюда не относится.
Кроме того, для precompiled app заменяй-не заменяй, приложение не отреагирует, если не перезагрузить домен приложения (например, обновлением web.config), а при выгрузке домена — свалится output кэш.
Для не-precompiled перезапись файла исходника также вызовет перезагрузку домена приложения — кэш теряется.
Не думаю, что это значительно влияет на производительность
>> не происходит обращение к базе даных
Имхо это плохо спроектированные контролы, если они ходят в БД, а не в кэш данных.
>>логика тут вынесена в базовый контрол
Я не про сложность добавления. Именно поэтому смешивается логика и данные: реализация двух методов заставляет каждый ваш контрол знать про кэш, про файлы и все остальное.
Вдобавок, своим решением вы сами себе поставили еще одну проблему — проблему очистки кеша. Она не сложная, однако — «нет кэш-файлов, нет проблем» )
Собстно, я не «наезжаю», просто хочу сказать, что в крупном проекте наличие такого решения, как ваше — борьба со следствием «тормозов» сайта, а не причиной; костыли для архитектуры, так сказать.
Я так понял, основная мысль в этом была )
А вы не в курсе, случайно, что это даст пользователям? Потому что имхо серьезные ошибки на шине связи — это нештатный режим однозначно, а в нем вряд ли кто-то планирует работать.