Виджет, main.php или как не нужно делать?!

[ksetrin]

В топике речь идет о "пять самых популярных и пять самых новых статей".
Вы всякий раз прибегаете к сервисам для "пять самых новых статей" ?
Что это сделать можно и будет даже по всем канонам правильно - я не спорю. Вопрос целесообразности. Тут из контекста вопроса напрашивается статика, и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.
Если уж будет много таких методов и вообще сложной логики, то безусловно нужны сервисы и прочие паттерны. Что считать сложным - вопрос риторический, и каждый ответит на него исходя из опыта. Если кому-то удобно элементарные задачи решать сложными методами, то пожалуйста. Кроме SOLID есть и другие принципы https://en.wikipedia.org/wiki/Best_codi ... ode_simple

[rugabarbo]

На самом деле SL (Service Layer) - это тема не для новичков. Я бы её стал советовать новичкам для ознакомления, но не для практики.

Практикуя сервисы, мы неизбежно сталкиваемся с массой проблем:
* универсальность API сервиса под все программные клиенты
* перехват событий происходящих в сервисе
* изоляция контроллеров от моделей (некоторые товарищи умудряются, внедрив SL, продолжать дёргать местами модели, а местами SL из контроллеров)
* и некоторые другие

Смотреть на результат применения SL новичками - это боль (:

Кто понимает английский, рекомендую видео: https://youtu.be/3uV3ngl1Z8g - хотя там даже без английского по демонстрируемому коду можно многое понять.

И повторюсь, ИМХО, новичкам SL - только для ознакомления. Практиковать новичкам лучше сначала всю бизнес-логику в моделях, а потом уже (по мере прихода осознания) начинать пробовать выносить бизнес-логику в сервисы.

Рост должен быть поэтапным. Никто не делает сразу приложения Enterprise-уровня. До этого нужно много лет расти.

[andrei.obuhovski]

В топике речь идет о "пять самых популярных и пять самых новых статей".
Вы всякий раз прибегаете к сервисам для "пять самых новых статей" ?
Что это сделать можно и будет даже по всем канонам правильно - я не спорю. Вопрос целесообразности. Тут из контекста вопроса напрашивается статика, и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

И чем хелпер целесообразнее сервиса?

[ksetrin]

В топике речь идет о "пять самых популярных и пять самых новых статей".
Вы всякий раз прибегаете к сервисам для "пять самых новых статей" ?
Что это сделать можно и будет даже по всем канонам правильно - я не спорю. Вопрос целесообразности. Тут из контекста вопроса напрашивается статика, и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

И чем хелпер целесообразнее сервиса?

Да вот как раз человек все хорошо написал, прямо перед вашим сообщением. Прочтите внимательно

[zelenin]

Тут из контекста вопроса напрашивается статика

каким образом здесь напрашивается статика?

и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

собственно мы его и сделали.

Вопрос целесообразности.

итак, вы вытащили напрямую здесь 5 новостей, вытащили в другом месте 10 новостей, решили в подвале разместить виджет с 20ю новостями. И тут херакс, сайт медленно работает. Начинаешь профилировать - AR подсирает. Решил отказаться от AR в пользу голых запросов (условно). И давай искать по всем местам где ты напихал AR-запросов. А тут просто зашел в сервис и поменял в одном месте.
Прелесть в том, что сервисный слой может быть реюзабельным и через год у тебя в проекте будет 1000 мест, где ты бы мог запихнуть голые AR-запросы, но вместо этого воспользовался 300 сервисами. Профит?
Но даже если у тебя заведомо нереюзабельный сервис, это не означает, что надо писать часть проекта в хорошем стиле, а часть левой лапой.

Если уж будет много таких методов и вообще сложной логики, то безусловно нужны сервисы и прочие паттерны. Что считать сложным - вопрос риторический, и каждый ответит на него исходя из опыта. Если кому-то удобно элементарные задачи решать сложными методами, то пожалуйста. Кроме SOLID есть и другие принципы https://en.wikipedia.org/wiki/Best_codi ... ode_simple

не-не-не, чувак. ты не правильно понимаешь принцип KISS. KISS пересекается с S в SOLID - принцип единой ответственности. У тебя должен быть максимально простой класс с одним функционалом. Если у тебя в классе происходит парсинг rss, разбор xml на чанки, сохранение в БД и валидация данных, то ты не KISS.
viewtopic.php?f=19&t=34474
посмотри ветку - там как раз нарушение всех принципов. Ниже я даю ссылку на мой коммит. Классов больше, но они все очень простые. При необходимости можно легко поменять конкретный класс без нарушения всей конструкции (правда надо еще ввести контрактную систему - интерфейсы). Если бы все было бы в одном методе собрано, это было больно во время рефакторинга или дебага ошибок.

[andrei.obuhovski]

Да вот как раз человек все хорошо написал, прямо перед вашим сообщением. Прочтите внимательно

Никто автору не предлагает сервисный слой выделять. У него одна логика в нескольких контроллерах используется, поэтому логично ее в класс-сервис выделить. Если бы эта логика только в этом экшне использовалась, то проще было бы в нем ее и написать.
А использовать хелперы для всего непонятного - зло.

[zelenin]

На самом деле SL (Service Layer) - это тема не для новичков. Я бы её стал советовать новичкам для ознакомления, но не для практики.

Практикуя сервисы, мы неизбежно сталкиваемся с массой проблем:
* универсальность API сервиса под все программные клиенты
* перехват событий происходящих в сервисе
* изоляция контроллеров от моделей (некоторые товарищи умудряются, внедрив SL, продолжать дёргать местами модели, а местами SL из контроллеров)
* и некоторые другие

Смотреть на результат применения SL новичками - это боль (:

Кто понимает английский, рекомендую видео: https://youtu.be/3uV3ngl1Z8g - хотя там даже без английского по демонстрируемому коду можно многое понять.

И повторюсь, ИМХО, новичкам SL - только для ознакомления. Практиковать новичкам лучше сначала всю бизнес-логику в моделях, а потом уже (по мере прихода осознания) начинать пробовать выносить бизнес-логику в сервисы.

Рост должен быть поэтапным. Никто не делает сразу приложения Enterprise-уровня. До этого нужно много лет расти.

не согласен со всеми тезисами.
* универсальность API сервиса под все программные клиенты
мы говорим об инкапсуляции, не об универсальности.
* перехват событий происходящих в сервисе
так наоборот удобнее триггерить событие в одном сервисе.
* изоляция контроллеров от моделей (некоторые товарищи умудряются, внедрив SL, продолжать дёргать местами модели, а местами SL из контроллеров)
это не минус сервисов, что чувак их не использует) разве можно сказать, что минус yii в том, что чувак где-то пользуется возможностями фреймворка, а где продолжает юзать plain php?

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

И повторюсь, ИМХО, новичкам SL - только для ознакомления. Практиковать новичкам лучше сначала всю бизнес-логику в моделях, а потом уже (по мере прихода осознания) начинать пробовать выносить бизнес-логику в сервисы.
не понимаю тезиса. SL - достаточно просто. В контексте темы это просто вынос некоей логики из контроллера и модели в отдельный обработчик.

[zelenin]

В топике речь идет о "пять самых популярных и пять самых новых статей".
Вы всякий раз прибегаете к сервисам для "пять самых новых статей" ?
Что это сделать можно и будет даже по всем канонам правильно - я не спорю. Вопрос целесообразности. Тут из контекста вопроса напрашивается статика, и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

И чем хелпер целесообразнее сервиса?

Да вот как раз человек все хорошо написал, прямо перед вашим сообщением. Прочтите внимательно

я прочел - честно, не увидел ни одного здравого довода. Мне кажется, он под сервисным слоем понимает коня в вакууме Шредингера.

[ksetrin]

Тут из контекста вопроса напрашивается статика

каким образом здесь напрашивается статика?

и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

собственно мы его и сделали.

Еще раз
"пять самых популярных и пять самых новых статей"

Да вот же, критерии
1 метод. самых популярных
2 метод. самых новых статей

5 это уже параметр, который будет передаваться.

>> собственно мы его и сделали
ШТА???
Судя по всему мы о разных сервисах говорим

[zelenin]

Да вот как раз человек все хорошо написал, прямо перед вашим сообщением. Прочтите внимательно

Никто автору не предлагает сервисный слой выделять. У него одна логика в нескольких контроллерах используется, поэтому логично ее в класс-сервис выделить. Если бы эта логика только в этом экшне использовалась, то проще было бы в нем ее и написать.
А использовать хелперы для всего непонятного - зло.

я так понимаю, вы оба подразумеваете разницу между хелпером и сервисом в наличии статических методов.
Ну ок. А по логике сервис и есть хелпер. Только тестируемый и с возможностью DI. А хелпер - кусок кала.

[zelenin]

Тут из контекста вопроса напрашивается статика

каким образом здесь напрашивается статика?

и можно сделать для начала класс-хелпер, который будет выдавать эти 5 статей.

собственно мы его и сделали.

Еще раз
"пять самых популярных и пять самых новых статей"

Да вот же, критерии
1 метод. самых популярных
2 метод. самых новых статей

5 это уже параметр, который будет передаваться.

>> собственно мы его и сделали
ШТА???
Судя по всему мы о разных сервисах говорим

viewtopic.php?f=19&t=34472&p=175289#p175289

[andrei.obuhovski]

я так понимаю, вы оба подразумеваете разницу между хелпером и сервисом в наличии статических методов.
Ну ок. А по логике сервис и есть хелпер. Только тестируемый и с возможностью DI. А хелпер - кусок кала.

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

[rugabarbo]

Саша, рост должен быть поэтапным. Новички с сервисами не справляются - факт (им бы более простые паттерны понять).

Мы же не заставляем детей сразу считать интегралы, правильно? Они сначала учат цифры, потом простейшую арифметику, таблицу умножения и так далее. До интегралов ребёнок растёт десяток лет.

Так и здесь - я не говорил про минусы SL. Я говорю про его сложности и проблемы, возникающие на практике. Изучать SL лучше всего в команде, которая его практикует. Только там новичкам дадут правильное понимание его работы.

А вот так на форуме всем советовать SL для любой задачи - (не знаю, как выразиться) ...бесполезно и даже, наверно, вредно для них. Ну сломают они шею себе на этом SL, а более простых вещей не поймут.

[zelenin]

Саша, рост должен быть поэтапным. Новички с сервисами не справляются - факт (им бы более простые паттерны понять).

Мы же не заставляем детей сразу считать интегралы, правильно? Они сначала учат цифры, потом простейшую арифметику, таблицу умножения и так далее. До интегралов ребёнок растёт десяток лет.

Так и здесь - я не говорил про минусы SL. Я говорю про его сложности и проблемы, возникающие на практике. Изучать SL лучше всего в команде, которая его практикует. Только там новичкам дадут правильное понимание его работы.

А вот так на форуме всем советовать SL для любой задачи - (не знаю, как выразиться) ...бесполезно и даже, наверно, вредно для них. Ну сломают они шею себе на этом SL, а более простых вещей не поймут.

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

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

[rugabarbo]

Суть не в сложности конкретного сервиса, а в сложности его дальнейшей поддержки (для новичка). Вынести выборку новостей в сервис - он вынесет. А дальше что? Огород костылей в этом слоёном пироге?

[zelenin]

Суть не в сложности конкретного сервиса, а в сложности его дальнейшей поддержки (для новичка). Вынести выборку новостей в сервис - он вынесет. А дальше что? Огород костылей в этом слоёном пироге?

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

[rugabarbo]

Я назвал проблемы поддержки сервисов выше.
Для новичка же главный минус SL - это повышение сложности системы за счёт доп.слоя.

[zelenin]

Я назвал проблемы поддержки сервисов выше.
Для новичка же главный минус SL - это повышение сложности системы за счёт доп.слоя.

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

Ты видишь, мы говорим противоположными тезисами. Свой я уже подтвердил. Попросил на примере приведенного сервиса подтвердить тебя свою точку зрения. Это не хорошо, что в ветке, которую будут читать новички, ты бездоказательно набрасываешь.

[ksetrin]

Я назвал проблемы поддержки сервисов выше.
Для новичка же главный минус SL - это повышение сложности системы за счёт доп.слоя.

Сомневаюсь, что вы сможете объяснить что-то. Он уже написал

Ну ок. А по логике сервис и есть хелпер. Только тестируемый и с возможностью DI. А хелпер - кусок кала.

И хоть по его же логике и следует сервис -> кусок кала, я даже за это цепляться не стал. Основное тут "сервис и есть хелпер". И хоть это действительно так, сервис и хелпер имею одинаковые цели, но реализации у них разные, и последствия реализаций тоже. Сам zelenin, я уверен, об этом прекрасно знает, но объяснить ему это на форуме, мне не представляется возможным.

[zelenin]

И хоть по его же логике и следует сервис -> кусок кала, я даже за это цепляться не стал.

ну чувак, что за нелепый вброс? Я разделяю понятия сервис и хелпер в угоду тебе, потому что для тебя это разные вещи. А для меня это одно и то же функционально. Только способ реализации другой. https://www.google.ru/search?q=php+why+ ... ygOJxILIBA

Основное тут "сервис и есть хелпер".

функционально. и там и там будут два метода дял получения данных.

И хоть это действительно так, сервис и хелпер имею одинаковые цели, но реализации у них разные, и последствия реализаций тоже.

и там и там на выходе ты получишь одинаковый набор данных.

Сам zelenin, я уверен, об этом прекрасно знает, но объяснить ему это на форуме, мне не представляется возможным.

то есть? что тебя останавливает? нет уж, изволь обяснить. Мне не нравится, когда чью-то точку зрения бездоказательно опровергают.