Задать вопрос
  • Как не превысить максимально допустимое количество Photos в таблице базы данных с одинаковым albumID?

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    Это делается с помощью бизнес-логики приложения. Решение на уровне базы данных тут не подойдёт
    Ответ написан
    3 комментария
  • Как получить данные с сервера, который запущен на ПК, который подключен к интернету через Android смартфон?

    2ord
    @2ord
    Для доступа к приложению на стадии разработки сойдет сервис Ngrok, создающий туннель в интернет.
    Ответ написан
    1 комментарий
  • Какой код ответа возвратить, если ресурс не существует и доступ к ресурсам этого же типа запрещен?

    solotony
    @solotony
    покоряю пик Балмера
    а какая разница ? что проверил первым то и возвращай. конечно если ошибки являются исключительными ситуациями, а не частью алгоритма
    Ответ написан
    1 комментарий
  • Какой код ответа возвратить, если ресурс не существует и доступ к ресурсам этого же типа запрещен?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Код ошибки в порядке следования цепочек проверок.
    401 - верно.
    Ответ написан
    Комментировать
  • Как правильно организовать аутентификацию(oauth2) через социальные сети на стороне rest api сервера?

    john36allTa
    @john36allTa
    alien glow of a dirty mind
    Решение: просто ответить на запрос со фронта, т.к. он был фэйсбуком редиректнут
    Ответ написан
    Комментировать
  • Как реализовать операцию, которая изменяет состояние нескольких aggregate roots, в приложении с распределённой базой данных?

    sarapinit
    @sarapinit
    Точу водой камень
    У Джимми Богарта в блоге есть серия постов по реализации распределенных транзакций. Можете начать с них.

    https://jimmybogard.com/life-beyond-transactions-i...
    Ответ написан
    Комментировать
  • Бросать исключение или возвращать коды ошибок/успеха? Является ли исключением то, что метод не может выполнить свою задачу?

    @freehostua
    Работаю в FREEhost.UA
    Исключения и сообщения об ошибках решают разные задачи. Если условно разделить приложение на Контроллер, формы проверки входных значений и модель приложения.

    Контроллер - управляет приложением
    Формы - выполняют валидацию данных
    Модель - основная логика, решение задачи бизнеса.

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

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

    Мое мнение такое:
    Если ошибка ожидаемая или ошибки должны накапливаться для отображения в диалоге с пользователем, это не исключение.
    Если ошибка незапланированная, приводит к немедленному прекращению выполнения алгоритма, значит это исключение. Пример исключения: ошибка взаимодействия с базой данных, ошибка записи на диск, вызов метода запрещенного для текущего состояния объекта.
    Ответ написан
    Комментировать
  • Бросать исключение или возвращать коды ошибок/успеха? Является ли исключением то, что метод не может выполнить свою задачу?

    Adamos
    @Adamos
    Пока вы вызываете одну функцию и решаете, что делать с ее ответом, вы не поймете исключений.
    Вот когда вам надо будет вызвать функцию, которая вызывает методы класса, которые вызывают методы других классов - вы либо изрисуете себе все стены теми вариантами ошибок, которые каждый из этих методов может вернуть, либо поймете, как это прекрасно - просто поймать исключение, если что-то пошло не так, и не париться с тем, что и где именно.
    Ответ написан
    3 комментария
  • Бросать исключение или возвращать коды ошибок/успеха? Является ли исключением то, что метод не может выполнить свою задачу?

    @xfg
    Исключения и есть современный способ реакции программы на ошибки, которые приводят к бессмысленности дальнейшего её выполнения. Соответственно, если у пользователя недостаточно средств для перевода, дальнейшее выполнение программы не имеет смысла, необходимо прервать её выполнение выбросив исключение. Когда этого механизма не существовало использовали коды ошибок.

    Вы также всегда имеете возможность посмотреть популярные open-source решения и убедиться какой точки зрения придерживается сообщество.
    Ответ написан
    1 комментарий
  • Бросать исключение или возвращать коды ошибок/успеха? Является ли исключением то, что метод не может выполнить свою задачу?

    glaphire
    @glaphire Куратор тега PHP
    PHP developer
    А поскольку пользователь может обойти и браузер и GUI

    Пользователь не должен уметь обходить, он должен иметь gui и/или api)

    Да, тема не самая легкая, но мне кажется, что вы забегаете наперед со слоями доменов и остальными понятиями ddd и паттернами.
    Exception должен указывать проблему на том уровне, на котором он возникает - исключение валидации на этапе валидации, исключение прав отправки денег на этапе проверки прав пользователя и т.д. Это решается нормальным распределением обязанностей классов и методов.

    Некоторые ошибки могут быть штатными в ряде случаев (как те же права пользователя) и не надо их эскалировать до исключения. Если пользователь может повлиять на исправление проблемы, то надо ему вернуть полный текст ошибки (нп. он должен пополнить счет, чтобы переслать сумму, поменять настройки или ввести правильные данные), если это чисто server-side ошибка, то естественно не надо показывать детали проблемы пользователю.
    Ответ написан
    6 комментариев
  • Бросать исключение или возвращать коды ошибок/успеха? Является ли исключением то, что метод не может выполнить свою задачу?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Бросать исключение или возвращать коды ошибок/успеха?

    Бросать исключение.

    Является ли исключением то, что метод не может выполнить свою задачу?

    Конечно же.

    Но узнать является ли сумма(amount) корректной по-хорошему можно только в браузере/GUI или в Domain слое в самом методе transferMoney().

    К фронту не должно быть доверия, данные обязательно нужно проверять.
    Аргументы метода лучше проверять И на тип И на граничные значения. Например ваш amount по идее должен быть float + больше, или равен 0. Если amount таковым не является - бросайте исключение. Логика выше должна была это отсечь, еще на этапе валидации данных запроса.

    В transferMoney() нужно извлечь данные пользователя(который пересылает деньги) из БД и проверить есть ли у него такая сумма.

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

    Получается в методе transferMoney() есть одна причина неудачи, а что если добавится ещё одна причина, например, пользователю запрещено временно пересылать деньги?

    Тот же комментарий, что и про баланс.

    Поскольку они ожидаемые, то бросать исключения не логично.

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

    В случае если бы была одна причина неудачи, то можно было бы просто вернуть false.

    Очень хреновая практика. Как вы определите в вызывающем коде, что пошло не так? Что "false"? Баланса не хватает, нельзя делать покупки, или Меркурий в ретрограде?

    возвращать что-то на подобии [false, $error] и [true, null]

    Для php - это очень кривой подход. По двум причинам:
    1. Вы расширяете интерфейс метода, просто так.
    2. Вы нагружаете вызывающий код дополнительными обвязками проверок, опять же просто так.
    В этом нет смысла так как есть механизм try-catch, который отлично решает это задачу.
    Вот пример, допустим ваш transferMoney($amount, User $recipient) должен возвращать объект транзакции, пусть его сигнатура будет:
    transferMoney(float $amount, User $recipient): Transaction
    Вызывающий код знает, что он обязан в конце получить транзакцию, а если что-то пойдет не так - будет исключение, нет смысла в дополнительных проверках, а что если первый элемент массива false, а что если он true, но второй элемент не null, а что если второй элемент не тот, что ожидалось, а что если первый элемент - строка, и т.д.

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

    Верно

    То есть transferMoney() выбросит исключение, которое подымется до Controller'a, и на основе которого Controller отправит 400 Bad Request и причину неудачи.

    Угу

    Или всё таки первый подход к проблеме лучше(первый абзац)?

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

    Вот вам еще чтива: https://github.com/index0h/php-conventions
    Ответ написан
    1 комментарий
  • Что должно находиться в инфраструктурном слое в многослойном приложении?

    xEpozZ
    @xEpozZ
    Веб-разработчик
    Всё, что не важно для бизнес-логики, должно быть вне domain-слоя.
    Разве бизнесу важно, как будет выстроен хеш пароля? (Несомненно, зависит от бизнеса, но в 90% случаев нет).
    Спросите об этом доменного эксперта или хотя бы менеджера.
    Они могут даже не знать, что такое "хеш" в принципе.

    А интерфейс лежит в домене, потому что нужно как-то соединить это "неважно" с "нужно".

    Даже если бы была только одна реализация, ее в примере вынесли все равно.

    Можно ли положить в домене? Вы строите систему. Хотите, положите в доменный слой, хотите, вынесите в микросервис. Хотите, пишите на PHP, или на Go или на C++.
    Как решите Вы, так и делайте.

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

    Есть моменты, которые будут меняться вне зависимости от вашей предметной области:
    обновления пакетов, уязвимости в безопасности при использовании чего-либо, новые быстрые реализации каких-либо модулей. В этом случае ваш бизнес-слой не должен быть подвержен изменениям. Но он четко должен знать, если вызовет реализацию этого интерфейса, то получит результат. Лишь это вы и должны гарантировать на бизнес слое.
    Ответ написан
    2 комментария