А что если банальные Update запросы это мышление в правильном направлении?Тот факт, что в итоге вся наша логика обернется банальными UPDATE запросами сильно мешает мышлению в правильном направлении...
Эвент сорсинг немного проясняет голову, но это мало кому нужная вещь
<?php
namespace Example;
class Users extends \System\SCRUD {
public $structure = [
'ID' => self::ID,
'ACTIVE' => [
'TYPE' => 'BOOL',
'NAME' => 'Active',
'DEFAULT' => true,
],
'LOGIN' => [
'TYPE' => 'STRING',
'NAME' => 'Login',
'NOT_NULL' => true,
'INDEX' => true,
],
'PASSWORD' => [
'TYPE' => 'STRING',
'NAME' => 'Password',
'NOT_NULL' => true,
],
];
public function Create($fields) {
$ID = parent::Create($fields);
UsersHistory::I()->Create([
'USER' => $ID,
'CHANGES' => $fields,
'EVENT' => 'Create',
]);
return $ID;
}
public function Update($filter = [], $fields = [], $event = 'Update') {
parent::Update($filter, $fields);
if ($event) {
$user_ids = $this->GetColumn($filter, 'ID');
foreach ($user_ids as $user_id) {
UsersHistory::I()->Create([
'USER' => $user_id,
'CHANGES' => $fields,
'EVENT' => $event,
]);
}
}
}
public function Ban(int $ID) {
$is_active = $this->Get($ID, 'ACTIVE');
if (!$is_active) {
throw new \System\Exception("User is already banned");
}
$this->Update($ID, ['ACTIVE' => false], 'Ban');
}
}<?php
namespace Example;
class UsersHistory extends \System\SCRUD {
public function Init() {
$this->structure = [
'ID' => self::ID,
'USER' => [
'TYPE' => 'OUTER',
'NAME' => 'User',
'LINK' => 'Users',
'NOT_NULL' => true,
],
'EVENT' => [
'TYPE' => 'STRING',
'NAME' => 'Event',
'NOT_NULL' => true,
],
'CHANGES' => [
'TYPE' => 'ARRAY',
'NAME' => 'Changes',
'NOT_NULL' => true,
],
'MOMENT' => [
'TYPE' => 'DATETIME',
'NAME' => 'Moment',
'NOT_NULL' => true,
],
];
}
public function Create($fields) {
$fields['MOMENT'] = time();
return parent::Create($fields);
}
public function Update($filter = [], $fields = []) {
throw new \System\ExceptionNotAllowed();
}
public function Delete($filter = []) {
$user_ids = array_unique($this->GetColumn($filter, 'USER'));
parent::Delete($filter);
foreach ($user_ids as $user_id) {
$this->Restore($user_id);
}
}
public function Restore(int $user_id) {
$history = $this->Select([
'SORT' => ['MOMENT' => 'ASC'],
'FILTER' => ['USER' => $user_id],
]);
$changes = [];
foreach ($history as $event) {
$changes = array_merge($changes, $event['CHANGES']);
}
// вызов Update с $event=null позволит обновить поля пользователя без записи в историю
Users::I()->Update($user_id, $changes, null);
}
}
по использованию global вижу, что твой опыт в хождении по своим же граблям невелик, ну либо работал в основном в одиночку и знаешь, где они разложены. Многие вещи понимаешь только после работы в разнородных командах, для себя-то можно как угодно делать, пока возраст позволяет все помнить.
Нет. это очень простой проектик. Приведу примерчик из книги моей
Там придется раскидывать это все по куче сущностей, которые представляют собой один агрегат. И сразу становится понятно, что все эти активрекорды, в которых нет нормального персиста релейшенов - это детские игрушки.
public function Ban это пример бизнес-логики,
public function ChangeLogin(int $ID, $new_login) {
$current_login = $this->Get($ID, 'LOGIN');
if ($new_login === $current_login) {
throw new \System\Exception("Same login");
}
$user_exist = $this->Present(['LOGIN' => $new_login]);
if ($user_exist) {
throw new \System\Exception("This login already used by another user");
}
$this->Update($ID, ['LOGIN' => $new_login], 'ChangeLogin');
}все еще надеюсь что вы научите меня как бы мне так хранить конфиг чтобы было лучше чем global
А, ну конечно, раз я сделал вручную, значит это не эвент сорсинг. Это даже лучше.
Я все )
Круто. Я рад, что кто-то с нашего форума находит на это время.
На запросы кругом все обмазываются всякими врапперами над активрекордами с анемикой, чот жесть прямо.
Пока где-то процента 3-4 от потраченного времени ) Если на часовую ставку пересчитать. Мало кому это все нужно...
В сыром виде всякие https://github.com/webonyx/graphql-php действительно неудобно использовать. По поводу активрекордов и анемики не очень понял, я сделаю запросы в CommandBus, в QueryServices и всё окей.А я по-старинке - типа-REST на запросы, JSON-RPC 2 на команды. Какой-нибудь ощутимый профит есть у GraphQL по сравнению с таким подходом?
Вот меня эта обвязка пугает, даже боюсь подойти к снаряду.
Ну там народ любит достать из базы только нужное. Мне это кажется сомнительной вещью - и с точки зрения вымывания кэшей, и с точки зрения излишней сложности. Хотя в конкретных случаях, наверное, полезно (типа, когда можно выбросить подзапрос). Если с этим не заморачиваться, то вроде все просто. Но опять же, см. пункт про ngrx.
Я не понял, честно говоря. Имеешь в виду, что современные фронт-фреймворки все равно запрашивают много лишних полей? Я просто совсем не разбираюсь в клиентском стаффе. Была, кстати, идея считать сложность запросов (каждое запрошенное поле — штраф) и выводить статистику куда-то по клиентам (web/iOS/Android). Команда с самыми «тяжелыми» запросами будет лишаться премии )
Ну это же не проблема GraphQL, мало ли что там любят.
GraphQL сейчас очень популярный формат, под все клиенты есть куча либ, тулз, клиенту проще как-то втягиваться, чем изучать очередную кастомную вариацию REST/JSON-RPC, плюс уже не возникает споров на тему разделения mutations/queries, людям дали авторитетный источник — ну всё, значит так надо.
В GraphQL ты можешь (точнее должен) выбрать какие-то поля у mutation при выполнении. Ты можешь выполнить команду и запросить нужные тебе read models в ответ.
Ага, сэкономили 50 байт на запросе, а потом втащили какой-нибудь jquery ui весом в пару мегабайт.
Ну не знаю, экономия на спичках это все.Да, для публичного API - согласен, тут без вопросов вообще.