Yii Framework

zelenin писал(а): Плюс магию нужно использовать там, где без нее обойтись нельзя.

Приведите случай, когда "нельзя обойтись". Она просто удобна бывает. Те же ActiveRecord в Yii2 можно было написать без магии, просто пользоваться было бы менее удобно.

mkramer писал(а):

zelenin писал(а): Плюс магию нужно использовать там, где без нее обойтись нельзя.

Приведите случай, когда "нельзя обойтись". Она просто удобна бывает. Те же ActiveRecord в Yii2 можно было написать без магии, просто пользоваться было бы менее удобно.

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

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

А проблемы поддержки SL, которые я перечислил, можно увидеть в видео, которое приложил в том же посте. Там достаточно компетентный человек показывает некоторые из этих проблемы и объясняет, как с ними справиться. Будет желание - посмотришь...

rugabarbo писал(а):Саша, говорить, что SL для новичка упрощает разработку - это необъективность, потому что от сервисов новичкам становится сложно (элементарно не понимают, что это). Для опытного разработчика - они многое упрощают, но уж точно не для новичка.
Необъективные разговоры мне неинтересны.

автор поста все понял. И я недоумеваю, кто может этого не понять. Ты льешь неаргументированную воду.

Видео гляну.

Что он понял? (: Мне кажется он охерел от того, что ему нужен доп.слой в системе для такой простой задачи

rugabarbo писал(а):Что он понял? (: Мне кажется он охерел от того, что ему нужен доп.слой в системе для такой простой задачи

viewtopic.php?f=19&t=34472#p175275

я не пойму, что ты несешь. Зачем ты усложняешь прсотую ситуацию.
Чуваку нужно вынести его два запроса и обернуть в класс. Добавится 3 строчки. В чем сложность?

видео кстати видел пару месяцев назад. правда не помню уже о чем.

rugabarbo писал(а):Что он понял? (: Мне кажется он охерел от того, что ему нужен доп.слой в системе для такой простой задачи

Автор поста не охренел и пытается разобраться в терминологии yii2.

ps У автора за плечами есть dBase, FoxPro und немного VFP. Посему, доп слой для решения простой задачи меня не пугает. Вопрос, как реализовать, ибо алгоритмами я понимаю прекрасно, но описать кодом пока не особо могу. Посему и нужны некие отправные точки для понимания того, как это реализуется сейчас, а не как во времена лисы.

я не пойму, что ты несешь.

В реале с людьми также общаешься? (:

Зачем ты усложняешь прсотую ситуацию.

То же самое хотел спросить у тебя: зачем ты усложнил простую ситуацию сервисным слоем? Речь о паре выборок.

Чуваку нужно вынести его два запроса

Да.

и обернуть в класс.

Зачем ему оборачивать это в целый отдельный класс? Почему не дополнительный статический метод в модели?

Добавится 3 строчки. В чем сложность?

В твоём пропагандировании сервисного слоя для задач всех калибров и масштабов. Нельзя же так (:

rugabarbo писал(а):

я не пойму, что ты несешь.

В реале с людьми также общаешься? (:

когда неаргументировано что-то пропагандируют, не реагируя на вопросы.

rugabarbo писал(а):

Зачем ты усложняешь прсотую ситуацию.

То же самое хотел спросить у тебя: зачем ты усложнил простую ситуацию сервисным слоем? Речь о паре выборок.

каким сервисным слоем? Одним сервисом aka хелпером

rugabarbo писал(а):

Чуваку нужно вынести его два запроса

Да.

и обернуть в класс.

Зачем ему оборачивать это в целый отдельный класс? Почему не дополнительный статический метод в модели?

а на каком основании модель должна включать в себя выборки? что такое модель? сущность. Она может включать фабричные методы создания сущности и методы работы над конкретной сущностью, но не сторонние выборки.

rugabarbo писал(а):

Добавится 3 строчки. В чем сложность?

В твоём пропагандировании сервисного слоя для задач всех калибров и масштабов. Нельзя же так (:

я предложил создание Application Service для инкапсуляции выборки. Пропагандируешь отказ от сервисного слоя ты. Впрочем беспричинно, посколько никто не ратовал за его безусловное внедрение, и безосновательно, поскольку ни одного критически обоснованного довода ты не привел.

А посмотрев видео, я понял, что тут вообще происходит. Ты увидел в видео критику различных подходов к архитектуре приложения, услышал слово service и теперь считаешь что сервисный слой - зло.
Но я предлагал внедрение одного сервиса как реализацию принципа SRP для реализации тонкого контроллера.
способов инкапсулировать выборку из базы - множество, сервисы, query, репозитории, различные файндеры, но только выборка в модели - за гранью зла.
А все почему? Потому программисты yii испорчены предложенными фреймворком паттернами. yii подталкивает к говнокоду.

Ты увидел в видео критику различных подходов к архитектуре приложения, услышал слово service и теперь считаешь что сервисный слой - зло.

Как можно общаться объективно, если постоянно сыплются подобные необъективные заключения с твоей стороны? (: Ты требуешь от остальных участников форума логичности и набрасываешься на людей за любую нелогичность, но сам частенько кидаешься подобными нелогичными выводами и умозаключениями.

1. Это видео я нашёл к теме, потому что вспомнил, что в нём наглядно показывают исходную модель и исходный контроллер (в виде конкретного кода), а потом также конкретно показывают, как из них выделить отдельный сервисный слой. Таким образом, это видео не является критикой различных подходов - оно наоборот объясняет, как сервисный слой выделить и правильно его обслуживать.

2. Я не считаю, что сервисный слой зло (: Я считаю, что плохо стрелять из пушки по воробьям. По крайней мере я не писал, что SL - это зло и давайте не будем его использовать. Ты просто не вникаешь в суть вещей и слышишь только себя.

Сказано ведь: SL для новичков - сложно на практике. Добавлено: ИМХО.

Не сказано: SL плохо всегда и для всех.

Почувствуй разницу.

zelenin писал(а):что такое модель? сущность

Сущность это орех в банке с другими орехами. Модель выполняет логику обмена данными с бд и логику приложения. На зарубежном форуме Й много раз это подтверждали в ответах и сами разработчики.
А говорить, что статический класс в модели зло, то же самое, что говорить это же про таблицы в html верстке. Всё может быть уместно.

SiZE писал(а):

zelenin писал(а):что такое модель? сущность

Сущность это орех в банке с другими орехами. Модель выполняет логику обмена данными с бд и логику приложения. На зарубежном форуме Й много раз это подтверждали в ответах и сами разработчики.
А говорить, что статический класс в модели зло, то же самое, что говорить это же про таблицы в html верстке. Всё может быть уместно.

По идее правильно использовать один класс для одной цели, и об этом неоднократно было сказано. Модель должна работать как модель. Работать с базой долен отдельный класс. Получил данные из базы, подгрузил эти данные в модель - и работай. В Yii с этим туго, и в моделях делают всё,ч то можно. Я видел модель в 4к строк,и считаю, что это не правильно

rugabarbo писал(а):

Ты увидел в видео критику различных подходов к архитектуре приложения, услышал слово service и теперь считаешь что сервисный слой - зло.

Как можно общаться объективно, если постоянно сыплются подобные необъективные заключения с твоей стороны? (: Ты требуешь от остальных участников форума логичности и набрасываешься на людей за любую нелогичность, но сам частенько кидаешься подобными нелогичными выводами и умозаключениями.

1. Это видео я нашёл к теме, потому что вспомнил, что в нём наглядно показывают исходную модель и исходный контроллер (в виде конкретного кода), а потом также конкретно показывают, как из них выделить отдельный сервисный слой. Таким образом, это видео не является критикой различных подходов - оно наоборот объясняет, как сервисный слой выделить и правильно его обслуживать.

2. Я не считаю, что сервисный слой зло (: Я считаю, что плохо стрелять из пушки по воробьям. По крайней мере я не писал, что SL - это зло и давайте не будем его использовать. Ты просто не вникаешь в суть вещей и слышишь только себя.

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

rugabarbo писал(а):Сказано ведь: SL для новичков - сложно на практике. Добавлено: ИМХО.

Не сказано: SL плохо всегда и для всех.

Почувствуй разницу.

сколько раз я уже попросил тебя объяснить сложность инкапсуляции двух методов в один сервис? Почему это может быть сложно для новичка? Это элементарно.

SiZE писал(а):

zelenin писал(а):что такое модель? сущность

Сущность это орех в банке с другими орехами. Модель выполняет логику обмена данными с бд и логику приложения. На зарубежном форуме Й много раз это подтверждали в ответах и сами разработчики.

логика обмена. И?
Сами разработчики - это кто? Я сам разработчик. И ты разработчик. Мартин Фаулер - разработчик.

SiZE писал(а):А говорить, что статический класс в модели зло, то же самое, что говорить это же про таблицы в html верстке. Всё может быть уместно.

в смысле нужно окончить разговоры о правильности чего-либо в программировании, ведь все может быть уместно?

zelenin писал(а):

rugabarbo писал(а):Сказано ведь: SL для новичков - сложно на практике. Добавлено: ИМХО.

Не сказано: SL плохо всегда и для всех.

Почувствуй разницу.

сколько раз я уже попросил тебя объяснить сложность инкапсуляции двух методов в один сервис? Почему это может быть сложно для новичка? Это элементарно.

Попробую ещё раз...

Сказано: SL для новичков - сложно на практике.

Не сказано: новичку сложно вынести два метода в один сервис.

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

Ясное дело, тронутся на гружёном камазе с прицепом не сложно. Всё как на легковой машине. Проблемы начнутся, когда новичок поедет на нём в гору по наледи.

Надеюсь, так моя мысль стала яснее...

SiZE писал(а):Запросы как минимум надо убрать в модель.

Думаю, что Вы имели в виду ActiveQuery, думая, что это тоже "модель". Репозитории в обиходе пока не прижились, а вот понятие "модель" обсудить стоит.

SiZE писал(а):Модель выполняет логику обмена данными с бд и логику приложения. На зарубежном форуме Й много раз это подтверждали в ответах и сами разработчики.

Вот с такой проталкиваемой разработчиками фреймворка предпосылки всё и идёт. Этим и укореняется в сообществе сужающее кругозор псевдопонимание, что Модель = ActiveRecord (или, в крайнем случае, экземпляр класса Model). И так уж сложилось, что ActiveRecord (в угоду упрощения, воспеваемого как основная концепция фреймворка) наследуется от Model, что позволяет обходиться лишь одним классом для всего кода.

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

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

Вот есть компонент Yii::$app->cache. Код его спокойно использует. И при этом нашей системе вообще не важно, куда он там пишет и откуда считывает: в файлы ли, в Memcache, в базу. Так и модель должна лишь делать своё дело, при этом никак не выполняя логику обмена данными с БД. Это не ей решать. Сохранять её или искать должны другие "люди".

А на практике часто что-то мешает. Думается, что пропиши правила преобразований значений из базы где-нибудь в конфиге и всё заработает из коробки. Но изначально ActiveRecord не имеет хоть как-то настраиваемого маппинга. В итоге все данные из базы и обратно попадают как есть, из за чего постоянная возня с возвратом строк вместо чисел и с преобразованием даты из timestamp в строку для DatePicker и обратно. Приходится на ровном месте костылить это в afterFind() и beforeSave().

А извечный вопрос "Толстые контроллеры или толстые модели?" не иссякнет никогда. Практически всегда ученикам говорю, что мало кто знает такую "страшную" тайну, что помимо контроллеров и "моделей" можно создавать и другие (!) классы. И это для многих уже шок, не говоря ещё о принципах написания тестируемого и поддерживаемого кода, инкапсуляции, единой ответственности, объектно-ориентированной парадигмы в общем и мышления на уровне интерфейсов в частности. Но это уже совсем другая история...

Дима, всё верно, но любая сложность должна быть оправдана. Давай посмотрим, что говорит про тот же самый сервисный слой Мартин Фаулер:

The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...]

But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.

Т.о. введение сервиса оправдано, если его действительно удаётся повторно использовать (задействовать один и тот же Service Layer в контроллерах сайта и в контроллерах API, например). Но вводить доп.слой просто для следования трендам - избыточно, нерационально.

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

Есть примеры, когда очень крупные Highload-проекты годами жили без QA-отделов. То есть вообще ничего не тестировали. Посмотрите историю технического развития Badoo, например. У них очень долго не было тестирования и отдела качества.

Увы, программирование всё больше становится похожим на моду: "Ребята, что там в тренде? Сервисный слой, авто-тесты, события, NoSQL-решения, ангулярка? Хм... А дай-ка я тоже всё это запихаю в свою разработку! Раз уж вы говорите, что это лучшие практики, то они явно не помешают." Всё меньше людей, способных рационально взвесить, что нужно использовать, а что нет.