SP
там как раз на примере "ордерс"
By default the Doctrine\ORM\Mapping\DefaultNamingStrategy uses the simple class name and the attribute names to generate tables and columns.
Size: a a a
2020 October 07
k
А зачем вам методы чтения в write модели (выше не читал, сорри, если не в тему)?
для устранения дублирования методов подсчёта, результат которых удобно считать, вместо того, чтобы записывать при изменении состояния.
Например есть промокод с ограниченной датой действия. Нужно заюзать промокод на такую-то дату, внутри проверяеем, что промокод ещё действует. Но на фронте тоже хочется видеть, что промокод ещё действует (например при вводе промокода пользователем, чтобы снизить вероятность фейла запроса).
В этой ситуации неудобно считать действует ли промокод на каждую из возможных входных дат, это удобнее вычислять каждый раз заново.
Например есть промокод с ограниченной датой действия. Нужно заюзать промокод на такую-то дату, внутри проверяеем, что промокод ещё действует. Но на фронте тоже хочется видеть, что промокод ещё действует (например при вводе промокода пользователем, чтобы снизить вероятность фейла запроса).
В этой ситуации неудобно считать действует ли промокод на каждую из возможных входных дат, это удобнее вычислять каждый раз заново.
DT
Фесора можно заменять ботом, который на любое упоминание кидает линк на all our aggregates are wrong. Ну и иногда спонтанно тоже кидает)
SP
За 5 сек
(new ArticleLike)->setArticle()->setUser()
persist flush
(new ArticleLike)->setArticle()->setUser()
persist flush
public function like(string $postId, string $userId)
{
$this->db->executeUpdate('INSERT INTO post_likes VALUES(:postId, :userId) ON CONFLICT DO NOTHING');
}
SP
вжух, 10 секунд фича готова
SP
нахуй вам ОРМ для таких фич непонятно
VS
ПГ
все так
Приветствую. Так задача вообще не имела проблем в количестве эндпоинтов. Проблема была как пропихнуть антиспам сложный в Рич модель.
SP
можно даже сделать так:
и потом в контроллере
namespace App\Likes;
class User
{
public function __construct(
private string $userId,
private Connection $db
} {}
public function like(string $postId): void {
$this->db->executeUpdate('INSERT INTO post_likes VALUES(:postId, :userId) ON CONFLICT DO NOTHING');
}
}
и потом в контроллере
namespace App\Likes;
class LikesController
{
public function like(User $user, string $postId) // обратить внимание что это юзер именно для лайков
{
$user->like($postId);
}
}
SP
Приветствую. Так задача вообще не имела проблем в количестве эндпоинтов. Проблема была как пропихнуть антиспам сложный в Рич модель.
это не должно быть в "рич модели".
k
public function like(string $postId, string $userId)
{
$this->db->executeUpdate('INSERT INTO post_likes VALUES(:postId, :userId) ON CONFLICT DO NOTHING');
}
тут есть 1 минус - из этого сложно построить большую и ветвистую диаграмму, смотрится несолидно =\ Как коллеги будут смотреть на меня после такого?
SP
мол это как обычно делают взрослые дяди.... делается некий user activity tracking - мол ты залогинился с таким-то айпишником и начал посты лайкать. Все эти ивенты сыпятся в какую-то шину где отдельная система на основе твоей активности принимает решение - так этот чел зарегался и как-то быстро начал лайкать посты одного и того же чела - забаним пидора"
тот же Уди Дахан для таких вещей предлагает использовать rules engine и это неплохо решает вопросы инкапсуляции
тот же Уди Дахан для таких вещей предлагает использовать rules engine и это неплохо решает вопросы инкапсуляции
SP
тут есть 1 минус - из этого сложно построить большую и ветвистую диаграмму, смотрится несолидно =\ Как коллеги будут смотреть на меня после такого?
мне проще - я уволить могу)
k
мне проще - я уволить могу)
ПГ
можно даже сделать так:
и потом в контроллере
namespace App\Likes;
class User
{
public function __construct(
private string $userId,
private Connection $db
} {}
public function like(string $postId): void {
$this->db->executeUpdate('INSERT INTO post_likes VALUES(:postId, :userId) ON CONFLICT DO NOTHING');
}
}
и потом в контроллере
namespace App\Likes;
class LikesController
{
public function like(User $user, string $postId) // обратить внимание что это юзер именно для лайков
{
$user->like($postId);
}
}
Подход интересный, но выходит что это какой то сервис класс.
SP
Подход интересный, но выходит что это какой то сервис класс.
а это мы потиху приходим к мысли что "сущности" не обязательно проекции табличек в базе)
SP
+ не совсе понятно как я из DI прокину UserID
class UserRepository
{
public function get(string $userId): User
{
return new User($this->connection, $userId); // к - каррирование
}
}
SP
ну то есть все в целом как обычно только нет ORM