http://dl1.joxi.net/drive/2016/12/17/0012/2839/817943/43/03b9e81541.jpg

Frontend что такое?)

там где юзеры водятся)

"публичная" и "приватная" часть у тебя называются frontend и backend?

дл я не авторизированного юзера

так себе)

yii напоминает

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

угу

никогда не понимал названия эти на бекнде "фронтэнд и бекенд"

у меня фронтэнд - это жс и браузер)

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

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

ну ок у меня есть 3 состояния

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

бек офис или админка

не авторизирова, авторизирован и админка

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

но с обрезанными правами

бек офис или админка

есть еще промежуточные штуки, merchant portal, whitelabel и т.д.

есть еще промежуточные штуки, merchant portal, whitelabel и т.д.

порталы бгг, есть такое) еще маркетинговая хрень у нас была

не авторизирова, авторизирован и админка

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

или он обычный пользователь но ему почему-то можно еще и модерировать что-то

так что нельзя говорить "у меня есть три состояния"

у тебя есть роли - возможно

суровые реалии

есть )

ну короч... я опять же повторюсь

группировать прикольнее по функционалу а не по "ролям"

да и блин

это контроллеры

я не знаю как у вас

а у меня контроллеры нужны только что бы связать http роуты и хэндлеры конкретные

зачем тебе тогда контроллеры?)

меня только в заблуждение вводит момент когда сервис возвращает результат и контроллеру его нужно отдать дальше(шаблон или жсон)

то ли нужно лепить отдельные форматтеры/принтеры, то ли сервисный слой сам этим должен заниматься в отдельной прослойке

ну у меня обычно за запись отвечают хэндлеры, и они частенько ничего не возвращают (могут исключение кинуть)

а для чтения у меня отдельные сервисы.

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

еще я не очень правильно юзал фрактал.... до недавнего времени

сейчас борюсь с последствиями

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

это все потому что их регать нужно, а это так впадлу)

есть такое

а че с фракталом не так?

а я чет думал что "инджектить сервисы в трансформеры збс идея"

по факту - нифига

лучше так не делать

очень провоцирует нарушать SRP

ну тоесть делать трансформеры как сервисы - идея дрянь

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

очень провоцирует нарушать SRP

самый мутный принцип

я могу описать последствия)

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

например появляются проверки вида "если текущий юзер может видеть email-ы юзеров покажи их"

а надо просто сказать трансформеру "и да показывай email-ы"

в этом заключается суть SRP - контект может захотеть поменять тот, кто юзает трансформер

и сделать это уже непросто потому что трансформер шибко умный

самый мутный принцип

жирная модель с сотней методов - это не нарушие SRP, это "доменный язык" а всякие сериалайзеры/десериалайзеры - это уже нарушение SRP ?

жирная модель с сотней методов - это не нарушие SRP, это "доменный язык" а всякие сериалайзеры/десериалайзеры - это уже нарушение SRP ?

жирная модель с сотней методов которая делает все сама - это нарушение SRP в большинстве случаев

делигируй унижай

передавай задачи другим сервисам

а вот нехера

просто нюанс

ты можешь передавать сервисы как зависимости операций, как аргументы

дабл диспатч и все такое

передавай задачи другим сервисам

делегирование ради уменьшения количества методов

делегирование ради уменьшения количества методов

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

ну SRP может быть то с разным скоупом

в смысле "скоупом"?

SRP - single reason to change. И все. у тебя поменялась логика подсчета скидок - должен поменяться один файл (или один компонент)

SRP - single reason to change. И все. у тебя поменялась логика подсчета скидок - должен поменяться один файл (или один компонент)

а если у меня бага? или оптимайзить надо?

а если у меня бага? или оптимайзить надо?

рефакторинги всякие это не изменения

баг - исправление функционала

рефакторинг - изменение реализации без изменений в функционале

оптимизации = рефакторинг

а вот когда тебе надо поменять функционал, именно логику работы

баг - исправление функционала

баг это те же требования, неучтенные как правило

и они могут задевать сразу много всего

от багов ты не застрахуешься)

вообще принципы SOLID это гадание, то есть ты никогда не сможешь знать всего наперед и не должен этого знать

SRP - single reason to change. И все. у тебя поменялась логика подсчета скидок - должен поменяться один файл (или один компонент)

у тебя еще нет кода. ты собрался его пилить

НО ты можешь хорошенько подумать

у тебя еще нет кода. ты собрался его пилить

не понял мысли

>у тебя поменялась логика подсчета скидок у тебя еще нет логики вообще, только требования и ты проектируешь систему

эм... ты так делаешь?

ну ладно, не суть

давай как ты описываешь

мой типичный день)

понедельник - пришел новый проект

кода нет

требования непонятны

так?

допустим они понятны)

ой да ладно, они никогда не понятны

давай конкретный кейс. подсчет скидок

тип "а давайте добавим подсчет скидок"?

или "а давайте поменяем алгоритм подсчета скидок"?

ну у тебя к примеру есть уже онлайн шоп

есть

а тут приходят и говорят - если чувак покупает 2 одинаковые книги, делаем ему скидку в 10 процентов

а если 3?

похер, 10%