Ответ на сообщение Re: Программист. пользователя Камон
Презрительно откомментировал, потому что "где надо" - это тоже отдельный уровень понимания программистом поставленной задачи. Вот где НЕ надо - они у Вас стоят... а где надо как раз и отсутствуют..
Как пример: ajax отправляет запрос серверу, на удаление данных из БД... на простой вопрос "энерпрайзу" а почему у тебя отсутствует код в блоке .onError()? недоуменное "а зачем?"... Гы. Пока смотрел страничку и отправлял запрос сессия протухла (1), сервер сдох(2), мускуль сдох(3), пришедший набор для удаления уже удален другим оператором(4), пришедший запрос нельзя обработать потому что данные уже ушли дальше по бизнес-модели и их банально нету(5)...
Думаете как народ пишет операцию вставки в БД? Просто! $this->insert(...); Фсё. Заворачивать в транзакцию серию таких операторов - нафига? Сервер БД сам разберется! Обрамлять кодом try{}catch{} - зачем? Исключение сверху поймают (там правда уже все равно сделать ничего нельзя...), проверять результат метода (а он иногда! только false возвращает, так сказать молча...) - вот же глупость какая!
... и ведь большинству просто недвомек, что сервер БД - это удаленная машинка, которая банально может быть выключена на момент операции...
а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя, а проверками в системе ваще-то занимается другой слой ПО... о чем и было писано и не токмо мною. Чего Вы опять же невнимательно читали... бывает. Там, кстати, большая часть кода - как раз проверки и остались. Только реально нужные...
Как пример: ajax отправляет запрос серверу, на удаление данных из БД... на простой вопрос "энерпрайзу" а почему у тебя отсутствует код в блоке .onError()? недоуменное "а зачем?"... Гы. Пока смотрел страничку и отправлял запрос сессия протухла (1), сервер сдох(2), мускуль сдох(3), пришедший набор для удаления уже удален другим оператором(4), пришедший запрос нельзя обработать потому что данные уже ушли дальше по бизнес-модели и их банально нету(5)...
Думаете как народ пишет операцию вставки в БД? Просто! $this->insert(...); Фсё. Заворачивать в транзакцию серию таких операторов - нафига? Сервер БД сам разберется! Обрамлять кодом try{}catch{} - зачем? Исключение сверху поймают (там правда уже все равно сделать ничего нельзя...), проверять результат метода (а он иногда! только false возвращает, так сказать молча...) - вот же глупость какая!
... и ведь большинству просто недвомек, что сервер БД - это удаленная машинка, которая банально может быть выключена на момент операции...
а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя, а проверками в системе ваще-то занимается другой слой ПО... о чем и было писано и не токмо мною. Чего Вы опять же невнимательно читали... бывает. Там, кстати, большая часть кода - как раз проверки и остались. Только реально нужные...
"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)
Исправлено пользователем tolstopuz (01.03.12 14:11)
