SP
p.s. http://david.tribble.com/text/goto.html - рекомендую разбор того письма 1968-ого года с пояснениями
Size: a a a
2020 October 07
k
Активность вычисляется относительно текущей даты. Модель активна 10 дней со дня создания + еще какие то условия относительно своих свойств.
Ещё вариант придумал. Вешаешь интерфейс на объект для записи (для того метода, который на чтение). А на read стороне маппить на тот же объект, но с другим интерфейсом
Это лучше варианта с функцией, потому что внутри может быть какой-нить VO с интерфейсом и в случае функции нужно будет полиморфизм руками прописывать, а так маппинг по типам раскидает и будет настоящий полиморфизм
Это лучше варианта с функцией, потому что внутри может быть какой-нить VO с интерфейсом и в случае функции нужно будет полиморфизм руками прописывать, а так маппинг по типам раскидает и будет настоящий полиморфизм
ПГ
Ещё вариант придумал. Вешаешь интерфейс на объект для записи (для того метода, который на чтение). А на read стороне маппить на тот же объект, но с другим интерфейсом
Это лучше варианта с функцией, потому что внутри может быть какой-нить VO с интерфейсом и в случае функции нужно будет полиморфизм руками прописывать, а так маппинг по типам раскидает и будет настоящий полиморфизм
Это лучше варианта с функцией, потому что внутри может быть какой-нить VO с интерфейсом и в случае функции нужно будет полиморфизм руками прописывать, а так маппинг по типам раскидает и будет настоящий полиморфизм
Мне кажется что то не очень. бизнес объект перегружен будет данными и логикой для чтения. Смысл как раз от этого уйти. Плюс могут быть приватные конструкторы или обязательные параметры в конструкторе. Какой то объект 2 в 1 получается.
ВУ
trait Softdeletable
{
public $deletedAt;
}
Entity{
use Softdeletable;
}
отличное применение трейтам в сущностях
{
public $deletedAt;
}
Entity{
use Softdeletable;
}
отличное применение трейтам в сущностях
🤮
D
а вы, стало быть, в каждую сущность прокидываете это дело отдельно да ?
ПГ
Приветствую, подскажите плиз грамотный путь работы с коллекциями в рамках инкапсуляции логики.
Кейс: есть статья, авторизированный пользователь может лайкнуть или убрать лайк со статьи - одним ендпоинтом, грубо говоря работает как тумблер. Есть сущность лайк, у нее ссылки на пользователя и статью.
В прямом случае я бы создал сервис, в нем метод и из репозитория дернул лайк по статье и пользователю, если его нет - создал, если есть - удалил. Задача готова.
Но нет же задачи в бизнес логике "создать/удалить лайк" есть "лайкнуть статью". Как я понимаю более верно было бы инкапсулировать в статье, юзере, или где?
Ну т.е. должно быть $article->likedBy($user) . Но тогда, чтобы найти лайкнута или нет, надо пробежаться по всей коллеции лайков, что дичь или использовать критерий внутри метода. Но тогда возникает вопрос, как пропихивать в метод какие то проверки, типа "антиспам лайков", который будет дергать БД или еще какие сервисы и т.д.
Что то короче меня замыкает между инкапсулировать в сущности и вынесенем в сервисы, что размазывает БЛ по сервисам.
Кейс: есть статья, авторизированный пользователь может лайкнуть или убрать лайк со статьи - одним ендпоинтом, грубо говоря работает как тумблер. Есть сущность лайк, у нее ссылки на пользователя и статью.
В прямом случае я бы создал сервис, в нем метод и из репозитория дернул лайк по статье и пользователю, если его нет - создал, если есть - удалил. Задача готова.
Но нет же задачи в бизнес логике "создать/удалить лайк" есть "лайкнуть статью". Как я понимаю более верно было бы инкапсулировать в статье, юзере, или где?
Ну т.е. должно быть $article->likedBy($user) . Но тогда, чтобы найти лайкнута или нет, надо пробежаться по всей коллеции лайков, что дичь или использовать критерий внутри метода. Но тогда возникает вопрос, как пропихивать в метод какие то проверки, типа "антиспам лайков", который будет дергать БД или еще какие сервисы и т.д.
Что то короче меня замыкает между инкапсулировать в сущности и вынесенем в сервисы, что размазывает БЛ по сервисам.
AP
Advanced Web Application Architecture
https://leanpub.com/web-application-architecture
Есть в кого-нибудь?
https://leanpub.com/web-application-architecture
Есть в кого-нибудь?
Р
Пиши уже include, что заморачиваться то
D
Приветствую, подскажите плиз грамотный путь работы с коллекциями в рамках инкапсуляции логики.
Кейс: есть статья, авторизированный пользователь может лайкнуть или убрать лайк со статьи - одним ендпоинтом, грубо говоря работает как тумблер. Есть сущность лайк, у нее ссылки на пользователя и статью.
В прямом случае я бы создал сервис, в нем метод и из репозитория дернул лайк по статье и пользователю, если его нет - создал, если есть - удалил. Задача готова.
Но нет же задачи в бизнес логике "создать/удалить лайк" есть "лайкнуть статью". Как я понимаю более верно было бы инкапсулировать в статье, юзере, или где?
Ну т.е. должно быть $article->likedBy($user) . Но тогда, чтобы найти лайкнута или нет, надо пробежаться по всей коллеции лайков, что дичь или использовать критерий внутри метода. Но тогда возникает вопрос, как пропихивать в метод какие то проверки, типа "антиспам лайков", который будет дергать БД или еще какие сервисы и т.д.
Что то короче меня замыкает между инкапсулировать в сущности и вынесенем в сервисы, что размазывает БЛ по сервисам.
Кейс: есть статья, авторизированный пользователь может лайкнуть или убрать лайк со статьи - одним ендпоинтом, грубо говоря работает как тумблер. Есть сущность лайк, у нее ссылки на пользователя и статью.
В прямом случае я бы создал сервис, в нем метод и из репозитория дернул лайк по статье и пользователю, если его нет - создал, если есть - удалил. Задача готова.
Но нет же задачи в бизнес логике "создать/удалить лайк" есть "лайкнуть статью". Как я понимаю более верно было бы инкапсулировать в статье, юзере, или где?
Ну т.е. должно быть $article->likedBy($user) . Но тогда, чтобы найти лайкнута или нет, надо пробежаться по всей коллеции лайков, что дичь или использовать критерий внутри метода. Но тогда возникает вопрос, как пропихивать в метод какие то проверки, типа "антиспам лайков", который будет дергать БД или еще какие сервисы и т.д.
Что то короче меня замыкает между инкапсулировать в сущности и вынесенем в сервисы, что размазывает БЛ по сервисам.
я не увидел тут проблему. у вас статья - агрегат, имеет доступ к инварианту - лайку
лайк привязан (к примеру) к статье через onetomany
вы можете сделать внутри статьи - hasLike
и потом сделать метод toggleLike($user){ if($this->hasLike)...}
лайк привязан (к примеру) к статье через onetomany
вы можете сделать внутри статьи - hasLike
и потом сделать метод toggleLike($user){ if($this->hasLike)...}
ПГ
я не увидел тут проблему. у вас статья - агрегат, имеет доступ к инварианту - лайку
лайк привязан (к примеру) к статье через onetomany
вы можете сделать внутри статьи - hasLike
и потом сделать метод toggleLike($user){ if($this->hasLike)...}
лайк привязан (к примеру) к статье через onetomany
вы можете сделать внутри статьи - hasLike
и потом сделать метод toggleLike($user){ if($this->hasLike)...}
Как прокинуть в него сервисы типа антиспама, который дергает инфраструктуру?