Yii Framework

sda писал(а):То есть entity может обращаться к репозиторию ?

sda писал(а):Непонятно. Дата маппер ведь уже возвращает готовую сущность, так почему нам надо воспользоваться репозиторием? Какие конкретно проблемы решает репозиторий, в отличии от дата маппера. Вот что хотелось бы услышать.

ElisDN писал(а):

sda писал(а):Непонятно. Дата маппер ведь уже возвращает готовую сущность, так почему нам надо воспользоваться репозиторием? Какие конкретно проблемы решает репозиторий, в отличии от дата маппера. Вот что хотелось бы услышать.

Маппер имеет только два метода, которыми умеет перегонять "объект в массив для SQL" и "SQL-результат в объект". Репозиторий же содержит кучу методов вроде find, findByEmail, findByUsername, где делает разные выборки и прогоняет SQL ответы через маппер. Маппер - всего лишь запчасть репозитория.

zelenin писал(а):вообще нет. это интерфейс непосредственной работы с БД, оперирующий сущностями, а не голыми скалярами. Соответственно функционал маппинга скаляров из бд к сущности там присутствует тоже, но не является частью интерфейса.

ElisDN писал(а):

zelenin писал(а):вообще нет. это интерфейс непосредственной работы с БД, оперирующий сущностями, а не голыми скалярами. Соответственно функционал маппинга скаляров из бд к сущности там присутствует тоже, но не является частью интерфейса.

Если рассматривать ORM целиком, то да. Если репозиторий автора сам перегоняет из скаляров в объекты, поддерживает вставку, обновление и удаление, то он полноценным маппером данных и является. Если же репозиторий использует отдельный маппер или сторонний ORM пакет, то это работает как его запчасть. В этом случае Data Mapper обычно является более низкоуровневым, чем репозиторий в контексте домена.

sda писал(а):Непонятно. Дата маппер ведь уже возвращает готовую сущность, так почему нам надо воспользоваться репозиторием? Какие конкретно проблемы решает репозиторий, в отличии от дата маппера. Вот что хотелось бы услышать.

sda писал(а):ElisDN, вот я и хочу разобраться, обязательно ли нужно городить дата маппер, а поверх него репозитории. Или можно всё же упростить и сделать чтобы репозиторий напрямую делал запросы в базу и сам создавал сущности? Не хочется всё усложнять, итак проект затягивается.

sda писал(а):То есть я могу создать в репозитории метод save, который умеет сохранять как одну сущность, так и массив сущностей. Это ничего не нарушает?

sda писал(а):ElisDN, спасибо. Скажите еще я верно понимаю что вот этот метод isPasswordResetTokenValid есть бизнес-логика доменного объекта User ? Естественно я осознаю, что нужно убрать зависимость от Yii::$app->params['user.passwordResetTokenExpire'] и вынести её как аргумент метода, а от аргумента $token наоборот избавиться, а сам метод сделать методом объекта, вместо статичного.

sda писал(а):Я успел прочитать ваше сообщение и даже написать на него ответ. Он ниже.

sda писал(а):Просто вроде доменная бизнес-логика должна быть инкапсулирована в сущностях, а так получается, что всё разбросано черт знает где и получается опять анемичная модель.

sda писал(а):Убедиться что токен сброса пароля является валидным, это доменная бизнес-логика.

sda писал(а):Зависимостей нет. Бизнес-логика внутри сущности.

sda писал(а):Я думал, что примерно вот так должно быть

class User
{
    public function assignPasswordResetToken($token, DateTime $expiredAt)
    {
        $this->passwordResetToken = new PasswordResetToken($token, $expiredAt);
    }
    
    public function hasValidPasswordResetToken()
    {
        if (empty($this->passwordResetToken)) {
            return false;
        }
        return $this->passwordResetToken->isValid();
    }
} 

sda писал(а):Инструкция $user->hasValidPasswordResetToken() вполне передает свой смысл.

public function hasValidPasswordResetToken(PasswordResetTokenizerInterface $tokenizer)
{
    if (empty($this->passwordResetToken)) {
        return false;
    }
    return $tokenizer->validate($this->passwordResetToken);
} 

sda писал(а):Ну или я ничего не понял в ddd. У вас было совершенно все по другому...

$timestamp = $this->passwordResetToken.split('_')[1];

$timestamp = (int) substr($this->passwordResetToken, strrpos($this->passwordResetToken, '_') + 1);

А где у Вас используется метод hasValidPasswordResetToken? Какой его смысл?

namespace application\services;

class RestoreService {
    ...
    restore($email) {
        $user = $this->userRepository->findByEmail($email);
        if (!$user->hasValidPasswordResetToken()) {
            $token = $this->securityService->generateRandomString();
            $user->assignPasswordResetToken($token);
            $this->userRepository->save($user);
        }
        //отправка письма на емайл что-то типа $this->mailerService->send(...);
    }
}

sda писал(а):В application layer использую, примерно вот так

class RestoreService {
    ...
    restore($email)
    {
        $user = $this->userRepository->findByEmail($email);
        $user->requestPasswordRestore($this->passwordTokenizer);
        $this->userRepository->save($user);
        // $this->mailerService->send(...);
    }
} 

class User
{
    public function requestPasswordRestore(TokenizerInterface $tokenizer)
    {
        if ($this->hasValidPasswordResetToken($tokenizer)) {
            throw new \DomainException('Token is already sent.');
        }
        $this->assignPasswordResetToken($tokenizer->generate());
    }

    private function hasValidPasswordResetToken(TokenizerInterface $tokenizer)
    {
        return $tokenizer->validate($this->passwordResetToken);
    }

    ...
} 

ElisDN писал(а):Нарушает типизацию и семантику. И сами методы с или ... или ... только усложняются кучами if-ов. Сделайте два отдельных метода: save(Item $item) и saveAll(array $items).

public function store(User ...$users)
{
   foreach ($users as $user) {
      $this->persist($user);
   }
}

private function persist(User $user)
{
  // Persist in storage
}

// Save one
$user = new User();
$repository->store($user);

// Save many
$users = [new User(), new User()];
$repository->store(...$users);

For reading, we do the same: we see Project as a complete unit, including its children, so when we fetch a Project, we get the full object graph.

Another benefit of all this encapsulation, is that Project can guard invariants for its set of Tasks. One such invariant could be a business rule stating that “Tasks can only be completed if the Project has at least five Tasks.” This business rule should not be guarded inside Task, but Project is a natural fit for it.