adelf/acwa_book_ru

Книга "Архитектура сложных веб-приложений. С примерами на Laravel"

acwa_book_ru's Issues

Зачем избыточный метод авторизации в FormRequest`ах?

В главе "Слой приложения", раздел "Передача данных запроса" есть такое предложение:

В моих проектах всегда есть базовый FormRequest класс, в котором метод authorize с одним оператором return true;, который позволяет забыть про авторизацию на этом уровне.

А зачем? В классе Illuminate\Foundation\Http\FormRequest проверяется существование метода authorize, и в случае его отсутствия считается, что авторизация пройдена (там тот же оператор return true). Можно просто не включать этот метод в свои классы.

Кастомные ошибки для ModelNotFoundException

В главе про обработку ошибок я так и не понял одну вещь. Допустим ситуация такая: я ищу запись в бд, и не нахожу ее. В зависимости от вида модели я хочу отправить клиенту сообщение об ошибке.
В контроллере у меня так
$promocode = Promocode::where('code', $request->promocode)->firstOrFail();

в случае если это аякс запрос, я хочу вернуть ответ в универсальном для меня формате. Для этого в handler.php в методе render я пишу следующее

Проблема тут в том, что я не могу из контроллера передать нужное мне сообщение об ошибке. Что тут можно сделать?

Структура проекта

Книга замечательная. Спасибо огромное !
После прочтения у меня остался вопрос. Как правильно создать структуру. В какую директорию сохранять Domain слой. Куда сохранить DTO(В одну директорию все или на поддиректории), и прочее. Очень хотелось бы увидеть пособие/пример. Если бы к книге был хоть манюсенький пример проекта(ссылка на github или даже платный вариант. Было бы здорово.). Пример в таком ввиде:
-DomainLayer
-DTO
--User
--Setting

Книга

Логика предложения уехала

"Если несколько разных типов сущностей, которые хранятся в одной таблице, еще можно представить и для Active Record библиотек, правда я ни на одном проекте такого не видел, то полноценную поддержку объектов-значений я не ещё не встречал"

Логика предложения уехала "не видели и не встречал" ожидается противопоставление "это не видел а это встречал"

Выборка по двум полям

Пишу простую аналитику для данных их crm системы. У меня есть 2 сущности: сделка Lead, и менеджер Responsible, который с этой сделкой работает. Для аналитики мне нужно сделать несколько выборок. Одна из них это получение по менеджеру сделок в статусе Оплачено, и в статусе Ожидает оплату

При этом приходится дублировать код в модели Responsible

Приходится это делать из-за того, что в eager load нельзя использовать алиасы

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

И вторая проблема с елоквентом. Структура таблицы leads такая, что связка с ответственным менеджером может быть как по полю responsible_id, так и по полю extra_responsible. Запрос на выборку сделок выглядит так:

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

Опечатка

Файл и раздел - https://github.com/adelf/acwa_book_ru/blob/master/manuscript/8-unit-test.md#%D0%BC%D0%BE%D0%BA%D0%B8-laravel-%D1%84%D0%B0%D1%81%D0%B0%D0%B4%D0%BE%D0%B2

Про именование интерфейсов

Здравствуйте, Адель!
Привожу цитату из книги:

Второй вариант: использование суффикса *Interface, например, создать интерфейс StorageInterface. Таким образом, имея класс Storage реализующий интерфейс StorageInterface, мы постулируем, что у нас есть интерфейс и его «главная» реализация. Все остальные реализации этого интерфейса выглядят вторичными. Само существование интерфейса StorageInterface выглядит искусственным: он был создан, чтобы код удовлетворял каким-то принципам, или просто для юнит-тестирования.

Это явление встречается и в других языках. В C# принят префикс I*. Интерфейс IList и класс List, например. В Java не приняты префиксы и суффиксы, но там часто случается такое:

class StorageImpl implements Storage

https://github.com/adelf/acwa_book_ru/blame/master/manuscript/2-di.md#L362

Вероятно здесь речь именно про то, что имя класса Storage плохое только если он реализует интерфейс с названием StorageInterface, т.к.

мы постулируем, что у нас есть интерфейс и его «главная» реализация

а не про то, что суффикс Interface нельзя или не стоит использовать для именования интерфейсов?
PSR обязывает использовать венгерскую нотацию для именования интерфейсов.

Архитектура сложных приложений

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

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

Архитектура сложных веб-приложений.

Latavel_book

Почему считается, что модели eloquent имеют минимум две ответсвенности?

В главе "Внедрение зависимостей" встретил следующую фразу:

Классы Eloquent моделей содержат как минимум две ответственности: хранение состояния сущности и выборку/сохранение/удаление сущностей из базы

В связи с этим, у меня возникли следующие вопросы:

1. Взаимодействие с базой это не часть ответственности по хранению данных? Я думаю хранение данных должно предусматривать взаимодействие с каким-либо персистентным хранилищем, иначе это не хранение.
2. Почему тогда, например, обязанности класса Request не определить как:

• хранение данных HTTP запроса
• парсинг HTTP запроса

Я считаю, что иметь состояние для класса в ООП это не обязанность. Все объекты в ООП (даже т.н. stateless сервисы) имеют состояние, взять хотя бы внутренний идентификатор, зависимости, конфигурацию. Почему наличие атрибутов с данными в моделях Eloquent считаются отдельной ответственностью?