Количество методов в классе, количество строк.

AmdY

Пью пиво
Команда форума
Тему закрывать не хочется, может кто по теме ещё выскажется. У меня по ходу обсуждения две идеи появились, нужно воплотить в код, благо выходные и погода отменила велопоход.

p.s. MVC здесь совсем ни при чём, не надо искать ветряные мельницы и героически с ними бороться. Так что заканчиваем меряться.
p.p.s. Тему подчищаю.
 
  • Like
Реакции: baev

caballero

Новичок
Тему закрывать не хочется, может кто по теме ещё выскажется.
Не выскажется - закрывай. Кому надо - тот высказался - остались только хомячки с цитатами из лурка.
 

AmdY

Пью пиво
Команда форума
caballero
у меня был хомячок, мы с ним ого-го как парнопрограммировали, т.к. у васи была замечательная черта - он никогда не спорил с моим экспертным мнением. может вам тоже завести, а не заводиться по пустякам и переходить на личности.

p.s. это тоже удалю попозже.
 

MiksIr

miksir@home:~$
Я еще не высказался.
caballero - толстый и его хорошо тут кормят. Во многом потому что сами были раньше такими толстыми, сейчас выросли и потешаются над другими. Забывая какими были сами.
Вот, теперь высказался.
По теме - вопрос, что в моделях, что в контроллерах, а что где-то еще - поднимался, так что поиск, поиск.
А мне вот интересно про сервисный слой... я так понимаю, он нужен тогда, когда у нас связанные модели, что бы вынести туда работу со связкой... а вот как его получать то в контроллере? Сервис-локатор и инжектировать?
 

caballero

Новичок
он никогда не спорил с моим экспертным мнением
я почему то считал что форумы на то и созданы чтобы спорить и высказывать мнения. В том числе и наши сирые и неэкспертные .
а не заводиться по пустякам и переходить на личности.
если потрудитесь перечитать я на личности первым не переходил и спорил не по пустякам а по теме которая возникла не от пустяка а от неудачного програмного решения.
Очень жаль что основными аргументами в обсуждении архитектуры являются ссылки на луркморе.
 

Ragazzo

TDD interested
MiksIr
а если "сервисный слой" как уже говорили что-то вроде HMVC то проще впринципе же, тупо форвардить на нужный контроллер и т д. м?
 

MiksIr

miksir@home:~$
А у меня сложилось ощущение, что fixxxer говорил о своеобразных хелперах... хотя кто знает что он имел ввиду, кроме него. Я просто пытаюсь представить как все будет жить с точки зрения DI.. очень интересна мне эта тема, хоть и теоретически пока.
 

caballero

Новичок
caballero - толстый и его хорошо тут кормят. Во многом потому что сами были раньше такими толстыми, сейчас выросли и потешаются над другими. Забывая какими были сами.
Вот, теперь высказался.
а ссылка на лурк где

По теме - вопрос, что в моделях, что в контроллерах, а что где-то еще - поднимался, так что поиск, поиск.
с вопросами проблем нет с ответами проблема.

А мне вот интересно про сервисный слой...
слой чего?
я так понимаю, он нужен тогда, когда у нас связанные модели,
чем и как связаные?
что бы вынести туда работу со связкой.
в чем заключается эта работа?

как говорил профессор Преображенский - "голубчик потрудитесь выражать ваши мысли яснее"

Сервис-локатор и инжектировать?
это PHP а не ява с персистентными объектами и аннотациями - не надо тупо переносить паттерны и IoС куда оно не лепится.
 

Redjik

Джедай-мастер
Ragazzo
MiksIr

Я как всегда с колокольни Yii.
Если есть связанные модели, а именно many_to_many, то делается отдельно моделька связка, и да, с ней уже напрямую и работает контроллер.
В других связях, например one_many, сама моделька подцепляет все нужные связи.
 

MiksIr

miksir@home:~$
2caballero: Слуш, крутой чувак, слейся на жава форум обратно к крутым пацанам. Дай спокойно лохам на этом форуме порассуждать о крутых штучках на примитивном убогом PHP.
 

caballero

Новичок
а если "сервисный слой" как уже говорили что-то вроде HMVC то проще впринципе же
HMVC - не сервисный слой (шо сие такое кстати ?) а костыль превращающий MVC паттерн в иерархию паттернов. Будет проще говорить о фрон-контроллере (или роутере) а дальше просто MVC.

просто пытаюсь представить как все будет жить с точки зрения DI..
слава Б-гу что хоть DI ограничился а не в IoC полез
 

MiksIr

miksir@home:~$
Ragazzo
MiksIr

Я как всегда с колокольни Yii.
Если есть связанные модели, а именно many_to_many, то делается отдельно моделька связка, и да, с ней уже напрямую и работает контроллер.
В других связях, например one_many, сама моделька подцепляет все нужные связи.
Ну я не про выборку, а про сохранение, скорее. Когда у нас изменение одной модели всегда подразумевает изменение другой.
 

caballero

Новичок
Дай спокойно лохам на этом форуме порассуждать о крутых штучках на примитивном убогом PHP.
Не все хотят оставатся лохами. бывают люди которые хотят чему то научится. Начни например учится отвеячать по существу.
Написали кучу умняков, наверно в расчете что никто не станет разбиратся и кричать "король голый"
я в такиъ случаях задаю уточняющие вопросы чтобы человек либо объяснил что хотел написать и это можно обсудить, либо понял что набор умных слов не всех впечатляет.
 

Redjik

Джедай-мастер
Продолжу мысль, есть еще ряд инструментов в YII для подобных вещей.
1) Это модули, но тут не интересно совсем.
2) Actions - это вот как раз по теме. Создаем класс который extends СAction, вот он и служит чем то вроде хелпера, в нем происходит какая то работа. В контроллере переопределяем родительский actions который возварщает массив... блин хреново получается обьяснить, вот пример с сайта
PHP:
class UpdateAction extends CAction
{
    public function run()
    {
        // place the action logic here
    }
}
И контроллер
PHP:
class PostController extends CController
{
    public function actions()
    {
        return array(
            'edit'=>'application.controllers.post.UpdateAction',
        );
    }
}
Таким образом мы выносим обработку в отлдельный класс. И можем подключать рутинные операции.
 

caballero

Новичок
Когда у нас изменение одной модели всегда подразумевает изменение другой.
модель это непонятно что - это может быть строка в таблице а может быть вся БД. Говори о сущностях (entity) тогда будет понятно. В частности не возникнет проблемы кода сущность по неведомой причине меняют другую сущность
 

caballero

Новичок
Таким образом мы выносим обработку в отлдельный класс. И можем подключать рутинные операции.
видимо что то типа паттерна Command - ну как минимум не будет свалки кода. Лучше много классов чем много строк в одном классе
 

MiksIr

miksir@home:~$
Начни например учится отвеячать по существу.
Только после вас. Как научитесь не троллить категориями sux/rulez, а обосновывать свое мнение на пальцах и с примерами, что бы "даже убогие PHP-ники поняли", тогда, может, вас начнут слушать и как-то воспринимать.
А пока из-за перлов типа "хоть DI ограничился а не в IoC полез" это сложно, да... хотя я понимаю, что IoC-контейнер имели ввиду, но не уверен, что вы это понимаете....
 

Ragazzo

TDD interested
Иван Redjik Матвеев
Не совсем то, тут пример с экшеном слишком не подходит :) все таки больше вопрос о том как модели связать, а не экшен пробросить :)
MiksIr
тут grigori недавно говорил как он делает, начинает валидацию с крайней связанной модели ну и соотвественно сохраняет также плюс все в одной транзакции насколько я понял.
 
Сверху