Не важно, каким именно образом строится оценка — путем непосредственного подстчета или же с помощью измерения отдельных параметров системы и вспомогательных вычислений.
Вы же не думаете, что когда где-нибудь в ускорителе подсчитывают число частиц определенного типа появившихся в результате реакции, что там сидит кто-то кто непосредственно считает эти частицы? Нет, там измеряются различные параметры системы, на основе которых в свою очередь строится оценка значения исследуемого параметра.
Лучше было бы начать с того, что обсуждаемая теория фактически не соответствует критерию фальсифицируемости, то есть не является научной. А уже после этого показать, что те случаи когда она работает — это все-го лишь устранение случайной погрешности.
Всё же зависит от ситуации. Пример: была необходимость, чтобы страничку могли редактировать люди, которые совершенно не разбираются ни в программировании, ни в верстке. Чтобы решить это был добавлен Смарти. В итоге например список файлов выглядит примерно вот так:
{assign var="page_title" value="Манга Death Note"}
Всем интуитивно понятно, что тут нужно исправить, если нужно. Это статика, меняется редко: прекрасно кэшируется средствами того же Смарти. Проблем и вопросов со стороны тех, кто вносит в файлы правки - 0.
Кстати, думаю позже стоит сделать при закачке файла поиск по хэшу дубликакта среди уже имеющихся - если система пойдет развиаться, то вы немало места сэкономите.
Если уж цитируете Вики, то делайте это полностью, чтобы не терять смысл:
Программа получила своё название в честь императора Нерона (англ. Nero), по легенде предавшего Рим огню. Благодаря игре слов, название программы Nero Burning ROM(E) может переводиться как «Нерон сжигает Рим» или как «Nero прожигает ROM (постоянное запоминающее устройство)».
Это не минус. Это плюс. Это всё ради того, чтобы обеспечить высокую совместимость. И опять же, Хибернейт предоставляет возможность использовать нативные SQL-запросы, если это нужно. Другое дело, что реальная необходимость возникает действительно редко. А собственно HQL - это обобщенный SQL, который Хибернейт сможет подогнать к любой БД.
У меня был опыт миграции с MySQL на Oracle без Хибернейта и с Хибернейтом. В первом случае мне пришлось вносить изменения чуть ли не в половину более-менее серьезных запросов. Во втором случае оказалось достаточно прикрутить нужный драйвер и подправить конфиг.
Что касается производительности. Если речь идет о проекте на миллионы пользователей, то тут конечно Хибернейт будет скорее мешать, чем помогать. В такие приложениях нужно всегда писать запросы максимально заточннные под конкретную задачу и конкретную БД. Если же речь идет о бизнес-приложении небольшого и среднего масштаба, то только за счет кэширования производительность вырастает в несколько раз.
Все эти "тысячи строк ненужного кода" генерируются срезствами IDE за пару секунд :)
А работать напрямую с базой хорошо, когда у вас
1) очень простая бизнес-логика,
2) нет сложной валидации данных,
3) низкие требования к производительности.
Собственно отдельная сессия под каждый запрос (как у автора) - это, конечно, не корректно. Обычно на один запрос к серверу - одна сессия Hibernate (да и транзакция в большинстве случаев - одна).
Не важно, каким именно образом строится оценка — путем непосредственного подстчета или же с помощью измерения отдельных параметров системы и вспомогательных вычислений.
Вы же не думаете, что когда где-нибудь в ускорителе подсчитывают число частиц определенного типа появившихся в результате реакции, что там сидит кто-то кто непосредственно считает эти частицы? Нет, там измеряются различные параметры системы, на основе которых в свою очередь строится оценка значения исследуемого параметра.
Я про «Мудрость Толпы»
...
Всем интуитивно понятно, что тут нужно исправить, если нужно. Это статика, меняется редко: прекрасно кэшируется средствами того же Смарти. Проблем и вопросов со стороны тех, кто вносит в файлы правки - 0.
Хотя как раз список "фэйловых" (в смысле плохих) был бы как раз был более актуален.
Программа получила своё название в честь императора Нерона (англ. Nero), по легенде предавшего Рим огню. Благодаря игре слов, название программы Nero Burning ROM(E) может переводиться как «Нерон сжигает Рим» или как «Nero прожигает ROM (постоянное запоминающее устройство)».
Сёрфинг — это вид водного спорта такой :)
У меня был опыт миграции с MySQL на Oracle без Хибернейта и с Хибернейтом. В первом случае мне пришлось вносить изменения чуть ли не в половину более-менее серьезных запросов. Во втором случае оказалось достаточно прикрутить нужный драйвер и подправить конфиг.
Что касается производительности. Если речь идет о проекте на миллионы пользователей, то тут конечно Хибернейт будет скорее мешать, чем помогать. В такие приложениях нужно всегда писать запросы максимально заточннные под конкретную задачу и конкретную БД. Если же речь идет о бизнес-приложении небольшого и среднего масштаба, то только за счет кэширования производительность вырастает в несколько раз.
А работать напрямую с базой хорошо, когда у вас
1) очень простая бизнес-логика,
2) нет сложной валидации данных,
3) низкие требования к производительности.