Если бы представление было хотя бы на смарти, было бы намного легче. То, что сейчас у нас, лучше не показывать неподготовленному человеку, знакомому хоть немного с MVC (:
Спасибо за Ваши комментарии, они действительно в самую точку :) Название статьи я подправил.
Касательно смены работы — думал об этом раньше, сейчас у нас наметились сдвиги в лучшую сторону, и очень хочется поучаствовать в этом :) ну а best practices хватает благодаря сторонним проектам на zf и magento.
Если заново перезагружать объект, то ничем не лучше, по сути. Если не перезагружать, то объект может ошибаться (добавить пост во внутреннюю коллекцию, но запрос на вставку сфейлится, например)
Я согласен. Но, бывают исключения.
Например, то, почему я связался с юнит-тестированием БД. Есть система, написанная и спроектированная в ~2004 году без всяких DAO. Система большая и работает (с костылями, но работает). Нас, как разработчиков она не устраивает, но она устраивает бизнес, потому что _работает_. Времени и средств на переписывание с нуля естественно никто не выделяет по причине «оно и так работает». Мы хотим «переписать» систему своими силами в процессе выполнения тасков. Для этого нужно покрыть все юнит-тестами.
Касательно смены работы — думал об этом раньше, сейчас у нас наметились сдвиги в лучшую сторону, и очень хочется поучаствовать в этом :) ну а best practices хватает благодаря сторонним проектам на zf и magento.
Например, то, почему я связался с юнит-тестированием БД. Есть система, написанная и спроектированная в ~2004 году без всяких DAO. Система большая и работает (с костылями, но работает). Нас, как разработчиков она не устраивает, но она устраивает бизнес, потому что _работает_. Времени и средств на переписывание с нуля естественно никто не выделяет по причине «оно и так работает». Мы хотим «переписать» систему своими силами в процессе выполнения тасков. Для этого нужно покрыть все юнит-тестами.
habrahabr.ru/blogs/java/112969/#comment_3622601