Понятно, он получает от функции в бизнес-логике true\false, и далее уже как-то показывает это в ui. Я получил ответ на свой вопрос, спасибо.

тип того, но лучше погуглить еще на тему валидации уникальных значений например

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

Понятно, он получает от функции в бизнес-логике true\false, и далее уже как-то показывает это в ui. Я получил ответ на свой вопрос, спасибо.

вот я бы как-то так делал наверное. Получить от БД ошибку или нет и дальшге решить, что с ней делать

Ок, а приведите пример исключительных ситуаций для выбрасывания exception?

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

вот я бы как-то так делал наверное. Получить от БД ошибку или нет и дальшге решить, что с ней делать

ну я так валидацию уникальных записей делаю

не прошла транзакция - ну значит что-то там есть)

а для UI есть простая проверочка

блин) я опечатался вместо БЛ - БД)

давай усложним - представь что у тебя нет бд)

Ну погоди, мы ж не про БД. Мы про ситуацию, когда контроллеру надо что-то провалидировать так, что это только слой БЛ может сделать

Так я бы не кидал скорее всего эксепшн в слое БЛ, а сделал, чтобы контроллер, получив ответ, что валидация не прошла - решал бы уже что делать, эксепшн или выдача ответа юзеру и тп

Хотя конечно это все "в среднем по больнице"

нужны конкретные примеры и желательно разные

По исключениям понял, спасибо. Ок, а если мне в контроллере на каждый такой случай надо опрашивать бизнес-логику, получается лапша из if-else. Не проще ли спросить из бизнес-логики одну функцию, которая вернет мне error_msg?

По исключениям понял, спасибо. Ок, а если мне в контроллере на каждый такой случай надо опрашивать бизнес-логику, получается лапша из if-else. Не проще ли спросить из бизнес-логики одну функцию, которая вернет мне error_msg?

какой каждый случай?

Допустим, у меня не только ip адресс должен быть уникальным, но и что-то еще (nickname, email, etc)

А почему вообще в конроллере?

Не подойдет ли тут какой- middleware например?

Допустим, у меня не только ip адресс должен быть уникальным, но и что-то еще (nickname, email, etc)

заворачиваешь в объект Identity и спрашиваешь один раз)

Который до контроллера валидирует поля и кидает экспешн в случае чего

Не подойдет ли тут какой- middleware например?

без разницы. это уже детали

Допустим, у меня не только ip адресс должен быть уникальным, но и что-то еще (nickname, email, etc)

давай так. уникальный nickname + email это какой-то трэш с точки зрения ux

ip это явно уже другое какое-то ограничение

давай так. уникальный nickname + email это какой-то трэш с точки зрения ux

я притянутый за уши пример привел, понятно что это треш

403

ну так давай реальные вещи обсуждать

потому что для трэша не стыдно и без объяснения причин вернуть

403 на поле, не прошедшее валидацию на уникальность?

Ну я бы очень удивился, получив такое

409 - конфликт

403 - нет доступа

у него ип как часть правила авторизации

422 - универсальный код для валидации

ip это явно уже другое какое-то ограничение

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

у него ип как часть правила авторизации

ну так это на уровне инфраструктуры все

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

давай так. В какой ситуации пользователь тебе булшит пришлет?

Судя по всему, регистрация чего-либо. так как сложно представить, что при логине проверяется поле на уникальность

Судя по всему, регистрация чего-либо. так как сложно представить, что при логине проверяется поле на уникальность

да блин чел

просто представь

ты пользователь

ты просто кликнул кнопку

вся эта инфа типа ip адрес или там юзер агент браузера - это он не должен контролировать

давай так. В какой ситуации пользователь тебе булшит пришлет?

Он может попытаться зарегаться по реф коду, который не существует. Может с одного ip пытаться зарегаться со своими реф кодами. И тд

и сообщать ему что "чел ты походу браузер сменил" как-то ну такое

ты так говоришь, будто я с тоббой о чем-то спорю)

Он может попытаться зарегаться по реф коду, который не существует. Может с одного ip пытаться зарегаться со своими реф кодами. И тд

ну так зачем заботиться что бы он просто и понятно понял что хочет наипать систему?

он делает нехорошие вещи - просто не давай ему делать и говори что он не хороший человек

заботиться надо только если ты хочешь что бы человек попробовал еще раз

ну так зачем заботиться что бы он просто и понятно понял что хочет наипать систему?

Мне это надо логировать. И сказать как-то что он нехороший человек

скажем чел неверно чето ввел при оформлении заказа

Мне это надо логировать. И сказать как-то что он нехороший человек

ивенты

доменные ивенты тут хорошо работают

EventStore::remember(IncorrectReferralInfo::occurred(data))

и записываешь ивенты

это наиболее универсальный но более сложный способ

@fes0r , пока ты тут, хочу спросить о другом. Ты же, если не ошибаюсь, докер используешь сейчас активно? Есть желание поспрашивать разные штуки, но где бы это удобнее сделать?) Тут чат все не про деплой

@fes0r , пока ты тут, хочу спросить о другом. Ты же, если не ошибаюсь, докер используешь сейчас активно? Есть желание поспрашивать разные штуки, но где бы это удобнее сделать?) Тут чат все не про деплой

есть чат про докер. там и спрашивай

Ну там я асбтракно спросил в никуда, так же абстрактно и молчат пока. Ну ок, я тебя понял

ивенты

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

заворачиваешь в объект Identity и спрашиваешь один раз)

можешь ткнуть носом в какой-нибудь пример с Identity?

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

нет конечно, можешь исключения логать, доступ к данным используемым у тебя ж есть

просто с ивентами было б неплохо тогда вообще все логать

и хорошее и плохое

и ответы с внешних сервисов

словом вообще все что бы можно было данные по этим ивентам восстановить

нет конечно, можешь исключения логать, доступ к данным используемым у тебя ж есть

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

(почти event sourcing просто чуть проще)

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

ну прикинь плюсы минусы)

ну прикинь плюсы минусы)

Для меня это однозначно плюс, т.к. я вообще пишу на питоне и простом фреймворке, тут нет мощного ООП каркаса типа как у Laravel, мне всё это с нуля реализовывать - большая трата времени. А сколько не глянь проектов с django\flask на гитхабе, люди вообще лепят всю бизнес-логику в контроллер и считают что это ок.

словом вообще все что бы можно было данные по этим ивентам восстановить

Благодарю за ответы.

Для меня это однозначно плюс, т.к. я вообще пишу на питоне и простом фреймворке, тут нет мощного ООП каркаса типа как у Laravel, мне всё это с нуля реализовывать - большая трата времени. А сколько не глянь проектов с django\flask на гитхабе, люди вообще лепят всю бизнес-логику в контроллер и считают что это ок.

Загугли django-rest dynamic_rest, там разнесенна логика, там куча всего из коробки не нужно изобретать ничего своего

Загугли django-rest dynamic_rest, там разнесенна логика, там куча всего из коробки не нужно изобретать ничего своего

гляну, спасибо

Привет! Подскажите пожалуйста, какой путь лучше выбрать в следующей ситуации? Пишу на TypeScript класс хранилища каких-то данных одного типа - не вдаваясь в детали - он должен уметь принимать функцию-загрузчик данных и иметь метод subscribe, который возвращает observable, выдающий загруженные данные. class ObservableList<T> { setLoader(loader: (...args: Array<any>) => /*вопрос тут*/): void {} subscribe(): Observable<Array<T>> {} // другие служебные методы типа merge/remove/reload/reset } Дело в том, что функции-загрузчики могут возвращать либо promise с массивом, либо Observable с таким же массивом(ангуляр у нас). Собственно, вопрос: как поступить с этим знанием того, что загрузчики бывают двух типов? 1) Сперва думал унаследоваться от этого класса и переопределять в новом метод setLoader, не трогая остальное. Например class ObservableListFromPromise<T> extends ObservableList<T> { setLoader(loader: (...args: Array<any>) => Promise<Array<T>>) } и такой же с Observable 2) Обойтись без наследования и ограничиться тем, что вызывать внутри загрузчик и проверять что он вернул - promise или observable - и от этого дальше танцевать. А может быть ни один из этих вариантов не хорош? Объясню зачем мне это - заметил, что часто в проекте встречается одинаковая работа по загрузке/обновлению/удалению данных в списках, и у таких списков несколько представлений в интерфейсе - сам список, фильтры над ним, аггрегаторы типа "100500 позиций, из них over9K таких и чуть-чуть вот таких". Поэтому захотел максимально унифицировать работу с ними и не писать каждый раз одно и то же

Ребята подскажите пожалуйста по Symfony 3, если кто в нем силен. Не работают роутинги на проде. Допустим localhost/app_dev.php - маршруты работают. localhost/app.php - тоже работают. а вот localhost/ - страница отображается, но при попытке перейти куда-то получаю 404. Кеш чистил, не помогает

Ребята подскажите пожалуйста по Symfony 3, если кто в нем силен. Не работают роутинги на проде. Допустим localhost/app_dev.php - маршруты работают. localhost/app.php - тоже работают. а вот localhost/ - страница отображается, но при попытке перейти куда-то получаю 404. Кеш чистил, не помогает

@symfony_php

@symfony_php

cпасибо

Привет! Подскажите пожалуйста, какой путь лучше выбрать в следующей ситуации? Пишу на TypeScript класс хранилища каких-то данных одного типа - не вдаваясь в детали - он должен уметь принимать функцию-загрузчик данных и иметь метод subscribe, который возвращает observable, выдающий загруженные данные. class ObservableList<T> { setLoader(loader: (...args: Array<any>) => /*вопрос тут*/): void {} subscribe(): Observable<Array<T>> {} // другие служебные методы типа merge/remove/reload/reset } Дело в том, что функции-загрузчики могут возвращать либо promise с массивом, либо Observable с таким же массивом(ангуляр у нас). Собственно, вопрос: как поступить с этим знанием того, что загрузчики бывают двух типов? 1) Сперва думал унаследоваться от этого класса и переопределять в новом метод setLoader, не трогая остальное. Например class ObservableListFromPromise<T> extends ObservableList<T> { setLoader(loader: (...args: Array<any>) => Promise<Array<T>>) } и такой же с Observable 2) Обойтись без наследования и ограничиться тем, что вызывать внутри загрузчик и проверять что он вернул - promise или observable - и от этого дальше танцевать. А может быть ни один из этих вариантов не хорош? Объясню зачем мне это - заметил, что часто в проекте встречается одинаковая работа по загрузке/обновлению/удалению данных в списках, и у таких списков несколько представлений в интерфейсе - сам список, фильтры над ним, аггрегаторы типа "100500 позиций, из них over9K таких и чуть-чуть вот таких". Поэтому захотел максимально унифицировать работу с ними и не писать каждый раз одно и то же

loader: () => Promise<T> | Observable<T>?

loader: () => Promise<T> | Observable<T>?

Ага, это тот самый второй вариант, который я описал. Ну т.е. наследование тут излишне ? Спасибо )

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

Было сомнение на тему как реализовать - унаследоваться два раза(ObservableListFromPromise и ObservableListFromRx) и переопределить один метод в них(setLoader), или написать if (loader instanceof Promise) { ... } else { ... } Сейчас прикидываю - наследование внесло бы путаницу - в какой части проекта какой класс использовать - от promise или от observable. А тут универсально - спрячу if и всем хорошо одинаково ?

Either ))

я не понимаю как наследование избавит от if (loader instanceof)

Точно ) Сперва спрашиваю, потом думаю ? От этого if никак не избавиться ) Вот как-то так предполагалось: class ObservableList<T> { private loaderType: 'promise' | 'rx'; private loadPromise() { this.loader().then().catch(); } private loadRx() { this.loader().subscribe()...; } private load() { this.loaderType === 'promise' ? this.loadPromise() : this.loadRx() } } } class ObservableListFromPromise<T> extends ObservableList<T> { setLoader(loader: (...args: Array<any>) => Promise<Array<T>>) { this.loaderType = 'promise'; ... } } и class ObservableListFromRx<T> extends ObservableList<T> { setLoader(loader: (...args: Array<any>) => Observer) { this.loaderType = 'rx'; ... } }

Всем добрый день. Возник вопрос[наброс]: в какой мере прнципы ООП применимы при проектировании REST API в микросервисной архитектуре? В моём представлении - SOLID он везде SOLID, но практика может отличаться от теории.

Всем добрый день. Возник вопрос[наброс]: в какой мере прнципы ООП применимы при проектировании REST API в микросервисной архитектуре? В моём представлении - SOLID он везде SOLID, но практика может отличаться от теории.

для начала у тебя не будет REST, у тебя будет что-то типа REST (на самом деле красивый RPC)

во вторых - микросервисы можно воспринимать как эктор модел

в третьих... это обмен сообщениями между экторами

то есть между модулями

ну а далее все вещи просто становятся менее явными

для начала у тебя не будет REST, у тебя будет что-то типа REST (на самом деле красивый RPC)

В этом месте немного неясно. Отчего "не REST"?

В этом месте немного неясно. Отчего "не REST"?

мне лень. Не переживай просто, ну нет у тебя rest, и раньше небыло и не будет никогда (нет гипертекста ж)

многие так живут и ничего

ты лучше другую мысль подумай

мне лень. Не переживай просто, ну нет у тебя rest, и раньше небыло и не будет никогда (нет гипертекста ж)

причём тут гипертекст...

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

то есть менее явно с одной стороны (скажем ты можешь LSP сломать если у тебя есть несколько реализаций одного микросервиса которые ты подменяешь)