Согласен, не очень адекватно получилось. Просто о squeryl я узнал в свое время именно из lift cookbook. И пытался сказать, что lift меня насторожил, а вот squeryl понравился.
Со Scala уже достаточно близко знаком. Но на Lift поглядываю с опаской все равно. Зато вот от Squeryl в восторге.
Ну и мне нравится писать clientside самому. Все таки clientside это то, что работает непосредственно у клиента. И не иметь возможность подтянуть какую-то часть, из-за того что ты этот кусок кода не контролируешь — не уверен что я могу себе это позволить.
Часть действий с распределенными системами контроля версий не имеет смысла. Если тесты выполнились до чьего-то push на работоспособность системы это не должно влиять.
Так как поддержать покупкой phpstorm не могу (ибо уже куплена), поддержал покупкой idea (надоело на community сидеть). Соответственно вопрос, когда в idea обновится плагин php?
Модель — это данные, там должна быть логинка по модификации этих данных, а роль конроллера — бизнес-логика и связи
Ох… Вы совершенно неправы…
За бизнес-логику в контроллерах надо бить по рукам.
Бизнес логика никогда не должна быть в контроллерах… Контроллеры отвечают только за потоки данных от пользователя и обратно.
Бизнес логика в контроллерах, это так же как бизнес-логика в представлениях — изменение интерфейса влечет за собой неизбежные изменения бизнес-логики. Контроллер это интерфейс для браузера.
Из гибкого backbone вы сделали фреймворк для монолитных, тяжело изменяющихся приложений.
Обоснуете?
Вам никогда не приходилось выносить часть интерфейска как одтельное модельное окно? или использовать готовый кусок интерфейса в другом интерфейсе?
Представления backbone прекрасны, потому что они говорят «я рисуюсь и делаю то-то». И не важно куда вставили это представление. Ему дают модель, и оно с ней работает. Такое представление может быть частью другого, и ничего об этом не знать.
У вас же есть контроллер который за всеми следит, и если вам нужно будет часть интерфейса в другом месте, вы будете дублировать этот код в другом контроллере.
Размазывать логику по многочисленным views очень не хотелось
Логика должна быть в моделях. Или это не MVC.
Так же требуется возможность создавать компоненты (views) и иметь возможность слушать их события
События надо слушать у моделей. Или это не MVC.
Из гибкого backbone вы сделали фреймворк для монолитных, тяжело изменяющихся приложений. Прелесть backbone в его гибкости, иначе теряется смысл его использовать.
Ну и мне нравится писать clientside самому. Все таки clientside это то, что работает непосредственно у клиента. И не иметь возможность подтянуть какую-то часть, из-за того что ты этот кусок кода не контролируешь — не уверен что я могу себе это позволить.
Так как поддержать покупкой phpstorm не могу (ибо уже куплена), поддержал покупкой idea (надоело на community сидеть). Соответственно вопрос, когда в idea обновится плагин php?
Спасибо!)
Ох… Вы совершенно неправы…
За бизнес-логику в контроллерах надо бить по рукам.
Бизнес логика никогда не должна быть в контроллерах… Контроллеры отвечают только за потоки данных от пользователя и обратно.
Бизнес логика в контроллерах, это так же как бизнес-логика в представлениях — изменение интерфейса влечет за собой неизбежные изменения бизнес-логики. Контроллер это интерфейс для браузера.
blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/
www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/
www.bennadel.com/blog/2379-A-Better-Understanding-Of-MVC-Model-View-Controller-Thanks-To-Steven-Neiland.htm
msdn.microsoft.com/en-us/library/ff649643.aspx
www.yiiframework.com/doc/guide/1.1/en/basics.best-practices
odetocode.com/Blogs/scott/archive/2009/04/06/putting-the-m-in-mvc-part-iii.aspx
gayleforce.wordpress.com/2009/11/28/model-view-controller-mvc-where-do-you-put-your-business-logic/
stackoverflow.com/questions/235233/asp-net-mvc-should-business-logic-exist-in-controllers
stackoverflow.com/questions/212027/where-are-the-business-rules-in-mvc
Вам никогда не приходилось выносить часть интерфейска как одтельное модельное окно? или использовать готовый кусок интерфейса в другом интерфейсе?
Представления backbone прекрасны, потому что они говорят «я рисуюсь и делаю то-то». И не важно куда вставили это представление. Ему дают модель, и оно с ней работает. Такое представление может быть частью другого, и ничего об этом не знать.
У вас же есть контроллер который за всеми следит, и если вам нужно будет часть интерфейса в другом месте, вы будете дублировать этот код в другом контроллере.
Логика должна быть в моделях. Или это не MVC.
События надо слушать у моделей. Или это не MVC.
Из гибкого backbone вы сделали фреймворк для монолитных, тяжело изменяющихся приложений. Прелесть backbone в его гибкости, иначе теряется смысл его использовать.