то есть что бы ты понимал, ответь на вопрос: - мы получим меньший каплинг между контроллером и persistence layer? - мы устраним дублирование? этот запрос нужен именно в таком виде и только тут. Так что никакого дублирования у нас нет. А городить слои просто так, это излишнее усложнение системы. - мы упростили тестирование? нет, весь этот код будет покрыт одним позитивным приемочным тестом

p.s. замена ORM это крайне редкий кейс

ок, а насколько редко меняют бд?

ок, а насколько редко меняют бд?

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

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

ну и еще - ты скинул штуку которая отвечает за операцию чтения

есть к примеру CQRS

ответь просто на вопрос - зачем выносить это дело?

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

я могу писать в sqlalchemy а читать через django

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

проще - потому что можно подменить имплементацию. Если ты подменишь имплементацию тут - то есть источник данных - ты будешь тестировать факт того что код компилится и не больше. По факту такие вещи, где нет никакой логики, достаточно покрыть приемочными тестами (end-to-end)

то есть... суть не в том что "умные люди не правы" - они правы, но ты обобщаешь эти слова ко всем случаям.

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

вот у меня в проекте текущем есть один контроллер в котором цикломатическая сложность прыгает за 20-ку. Вот это - говно)

и я это рефакторю)

и там не "в сервисы" выношу, а стараюсь найти логике достойного владельца (сущности, объекты значения)

сервисы же - если все совсем плохо

ну либо инфраструктура, либо это вне контекста сущности

я обобщаю, т.к. у меня нет опыта построения таких проектов, я пытаюсь выяснить все + и - такого подхода. Я не хочу опять разводить холивар, но ведь всякие DDD, гексагоняльные и тд архитектуры явно принуждают нас отделять application level и business level. В данном случае - контроллер есть application level, т.е. что будет если мне тут надо срочно поменять django на <другой фреймворк> (в теории конечно же)

я обобщаю, т.к. у меня нет опыта построения таких проектов, я пытаюсь выяснить все + и - такого подхода. Я не хочу опять разводить холивар, но ведь всякие DDD, гексагоняльные и тд архитектуры явно принуждают нас отделять application level и business level. В данном случае - контроллер есть application level, т.е. что будет если мне тут надо срочно поменять django на <другой фреймворк> (в теории конечно же)

но тут нет buisness level - тут только application level)

на другой фреймворк никто проекты тоже не переводит

ну как, а languages = sorted(list(set(settings.AMO_LANGUAGES) - set(['en-US']))) это все еще app level чтоле?

важно buisness layer от фреймворка отгородить (инверсия зависимостей и все такое)

ну как, а languages = sorted(list(set(settings.AMO_LANGUAGES) - set(['en-US']))) это все еще app level чтоле?

ну а что это?) бизнес логика?)

> у меня нет опыта построения таких проектов ну так строй) напиши маленький убер) а то у меня все руки не доходят. Довольно простой проект который можно "менять"

запуш все на гитхаб, а тут будут обсуждать почему "говно" и как лучше)

> у меня нет опыта построения таких проектов ну так строй) напиши маленький убер) а то у меня все руки не доходят. Довольно простой проект который можно "менять"

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

> что будет если мне тут надо срочно поменять django на <другой фреймворк> (в теории конечно же) все эти примеры в духе "можно заменить фреймворк" или "можно заменить базу данных" являются проявлением качества абстракции. Увы, абстракции любят течь (компромис в сторону производительности например). А потому нам выгоднее иметь тот тип абстракций, который позволяет нам не от выбранного SQL диалекта абстрагироваться. Суть в том что бы всю эту работу с SQL спрятать за красивым интерфейсом. То есть если вдруг ты решишься перевести проект с mysql на orientdb какой - то это не просто взял и заменил - это придется дофига переписывать. Но за счет абстракции изменения будут изолированы от всего остального проекта.

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

или вот тебе еще пример, тот же убер

у нас там можно будет выделить несколько "подсистем". одна - собственно пользователи. Там все тупо, можно хоть крудом делать. Вторая - геопозиции, трекинг авто и т.д. - тут нам уже важно на запись хотя бы абстракцию вводить, какой-нибудь persistence ignorance. Оно как бы все еще 2 слоя не больше ибо все просто. А вот для операций чтения можно вообще на слои особо не делить. И третья подсистема - сами поездки. Самая важная. Тут уже нам выгодно CQRS + Event Sourcing

то есть один проект, даже монолит, может включать в себя очень разные подходы и идеи

инструмент под задачу так сказать

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

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

запись - реквест без респонса, чтение - сокеты)

возьми centrifugo например)

ну да, машинки двигать самое то

ну да, машинки двигать самое то

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

> что будет если мне тут надо срочно поменять django на <другой фреймворк> (в теории конечно же) все эти примеры в духе "можно заменить фреймворк" или "можно заменить базу данных" являются проявлением качества абстракции. Увы, абстракции любят течь (компромис в сторону производительности например). А потому нам выгоднее иметь тот тип абстракций, который позволяет нам не от выбранного SQL диалекта абстрагироваться. Суть в том что бы всю эту работу с SQL спрятать за красивым интерфейсом. То есть если вдруг ты решишься перевести проект с mysql на orientdb какой - то это не просто взял и заменил - это придется дофига переписывать. Но за счет абстракции изменения будут изолированы от всего остального проекта.

Я так понимаю, что в твоем "понимании" - если можно не выделять абстракцию, то лучше не выделять (в сервисы, паттерны etc), ибо может получится FizzBuzz Enterprise edition. Ок, но где найти ту грань, т.к. еще вчера для меня контроллер - это принять request, создать контекст, отдать response, а сегодня - в нем уже напрямую можно вызывать классы моделей, валидировать и фильтровать модели итд

неинтересно) хоть и сложно может быть, но руками больше пользы

неинтересно) хоть и сложно может быть, но руками больше пользы

я когда пытался делать у меня за это отвечала маленькая хрень написанная за пол часа с рэдисом и symfony

ну то есть это не сложно

там потом просто можно докручиваьт аналитику и тд.

я вон твое описание слоев закинул себе в сохранки, потом в трелло унесу там уже штук 5 на сделать лежит

и ещё две в голове

я же по глупости пытаюсь сразу правильно делать) пока ещё не поймал дзен

Я так понимаю, что в твоем "понимании" - если можно не выделять абстракцию, то лучше не выделять (в сервисы, паттерны etc), ибо может получится FizzBuzz Enterprise edition. Ок, но где найти ту грань, т.к. еще вчера для меня контроллер - это принять request, создать контекст, отдать response, а сегодня - в нем уже напрямую можно вызывать классы моделей, валидировать и фильтровать модели итд

грань субъективна. Один их неплохих вариантов как ее щупать - через тесты. Например контроллер который ты привел нет смысла тестировать юнит тестами так как он целиком покрывается за один прогон приемочных тестов (а приемочные тесты нужны). Вот если бы там начиналась какая-то логика, обработка эдж кейсов и т.д. то мы бы возможно захотели юниты. И тогда встал бы вопрос куда вынести логику, что бы и количество зависимостей было на минимуме, и удобно тестировать и вообще все круто

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

это оффтоп, всё правильно

грань субъективна. Один их неплохих вариантов как ее щупать - через тесты. Например контроллер который ты привел нет смысла тестировать юнит тестами так как он целиком покрывается за один прогон приемочных тестов (а приемочные тесты нужны). Вот если бы там начиналась какая-то логика, обработка эдж кейсов и т.д. то мы бы возможно захотели юниты. И тогда встал бы вопрос куда вынести логику, что бы и количество зависимостей было на минимуме, и удобно тестировать и вообще все круто

ок, но почему нет смысла то? А прочекать шаблон (мб его удалил кто) или прочекать результат с модели?

ок, но почему нет смысла то? А прочекать шаблон (мб его удалил кто) или прочекать результат с модели?

все это покрывается одним end-to-end сценарием

ок, но почему нет смысла то? А прочекать шаблон (мб его удалил кто) или прочекать результат с модели?

так речь про принял - отдал в сервис - вернул ответ

и этот end-to-end сценарий должен быть

когда говорят "e2e тестов должно быть мало" имеется ввиду что только позитивные сценарии. В нашем случае тут сценарий только один.

и этот end-to-end сценарий должен быть

скажи это тестерам)

скажи это тестерам)

я тебе говорю) QA пусть занимаются эксплорейшен тестингом)

или ты про те, что с нашей стороны?

ERROR: S client not available

грань субъективна. Один их неплохих вариантов как ее щупать - через тесты. Например контроллер который ты привел нет смысла тестировать юнит тестами так как он целиком покрывается за один прогон приемочных тестов (а приемочные тесты нужны). Вот если бы там начиналась какая-то логика, обработка эдж кейсов и т.д. то мы бы возможно захотели юниты. И тогда встал бы вопрос куда вынести логику, что бы и количество зависимостей было на минимуме, и удобно тестировать и вообще все круто

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

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

то что я скинул - лишь упражнение

я тебе говорю) QA пусть занимаются эксплорейшен тестингом)

а как же automate qa?

а как же automate qa?

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

но да, это приёмка, это не e2e (вроде)

но да, это приёмка, это не e2e (вроде)

приемка через e2e обычно и делается

у нас есть несколько но их мало и они медленные

и этот end-to-end сценарий должен быть

end-to-end это я так понимаю затестить руками\селениумом?

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

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

end-to-end это я так понимаю затестить руками\селениумом?

да, с точки зрения пользователя как будет, чисто black-box тестирование.

селениум на джаве и бехаты всякие над ним или над фантомом - это какие тесты?

селениум на джаве и бехаты всякие над ним или над фантомом - это какие тесты?

фантом - интеграционные обычно....

хотя для js и юниты запускают)

хотя не... это все еще интеграционные тесты

ой блин, я запутался в терминологии ведь интеграционки - это взаимодействие модулей

интеграционка это когда без изоляции, да)

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

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

а фантом - это считай тест от имени юзера ну или селениум

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

по поводу гимнастики - это хорошее упражнение что бы ты вообще начал задавать вопросы в духе "как так без геттеров!?" или "как так только 3 поля на класс?"

а фантом - это считай тест от имени юзера ну или селениум

фантом = онли вэбкит

я пока грань между e2e и приемкой не вижу

причем не самый новый вроде, не слежу

я пока грань между e2e и приемкой не вижу

ммм... ее и нет, приемка это e2e)

фантом = онли вэбкит

ну да, логично ещё есть headless chrome

окей, уже хорошо)

ну может я не прав, но я это отождествляю