Сущности и триггеры описываются мною в Nushpere Phped, разумеется для каждого проекта они разные. В складском учете нет понятий трафика, IP адресов, а в биллинге нет приходных накладных :) Для каждого проекта разные и валидаторы, проверить наличие товара на складе для его расхода и правильность введения IP адреса — имеют мало чего общего, согласитесь.
зачем 50? тут 10 строчек, и да, помогут. Какие сложности?
Отделяем сущности (абонент, договор, сервис, гроссбух, оператор, адрес и т.д.),
делаем SQL таблицы (с references по id), триггеры, функции (перекладываем часть логики внутрь БД), и только потом 10 строчек нам начнут помогать загружать плагины customer, service, contract и пр.
А какую методику используете вы?
Странно, что мало кто работает на уменьшение кода, обычно код фреймворка все время увеличивается, вбирая в себя мелкие велосипеды, 50% из которых никому не нужны. Почему никто не скажет — довольно, хватит палить из пушки по воробьям, давайте сделаем лайт версию нашего монстра, а остальное по мере надобности подключат плагинами?
Ну уж нет. Если его хватило для полнофункционального биллинга, то обрастать ему никак не требуется. Да и зачем? И так хватает всяких монстров, тут уж велосипед действительно не стоит изобретать.
Ну да, именно ПРОЗРАЧНОГО дергания. А не закрытого дергания иерархии классов (где управление уходит к ядру земли и непонятно что вернет в ответ). Не стал описывать все детали, но тут кто-во-что-горазд не получится :) Тут как раз всё чОтко. Объект-и-действие весьма конкретны.
Да, по замыслу, в этом фреймворке могут использоваться любые шаблонизаторы, API c SQL, движки Javascript. Чтобы не переучиваться :) Все-в-одном не всегда есть гут.
Отделяем сущности (абонент, договор, сервис, гроссбух, оператор, адрес и т.д.),
делаем SQL таблицы (с references по id), триггеры, функции (перекладываем часть логики внутрь БД), и только потом 10 строчек нам начнут помогать загружать плагины customer, service, contract и пр.
А какую методику используете вы?