нет
Этот шаблон упаковки неструктурированных данных в типы, чтобы мы могли использовать наши данные надежным способом, называется “объекты передачи данных” или DTO (Data Transfer Object). Вроде под определение подходит. Почему нет? Нет валидации?
Прочитав пару раз эту статью, я могу сделать вывод, что это все-таки DTO, но в примере DigitalOceanPHP/Client нет никаких гарантий, что данные относятся к тому типу, о котором они говорят, так как используется только docblocks. Не могу спорить, так как не хватает опыта. Но если бы была еще одна точка зрения, то было бы отлично :) https://maxyc.ru/programming/dto-intro/
Тоже думаю, что нет. DTO обычно не содержит никакой логики. Это просто класс, чтобы переместить данные, учитывая их типы. Иногда туда добавляют правила валидации (через аннотации или атрибуты). Если там какая-то логика по преобразованию, то это уже не просто dto, а что-то посерьёзнее
То есть, если бы в \DigitalOceanV2\Entity\AbstractEntity были только \DigitalOceanV2\Entity\AbstractEntity::__construct и \DigitalOceanV2\Entity\AbstractEntity::build, то это был бы DTO? \DigitalOceanV2\Entity\AbstractEntity::build - это по сути этот код отсюда, только более универсальный: public function fromRequest(CustomerRequest $request): CustomerData { return new CustomerData([ 'name' => $request->get('name'), 'email' => $request->get('email'), 'birth_date' => Carbon::make( $request->get('birth_date') ), ]); }
У DO абстрактный класс, который сам по себе пользы не несет (и инстанцировать его не получится). От него подразумевается, что нужно отнаследоваться, чтобы получить необходимую функциональность: конструирование с любым количеством параметров, переданным в массиве. Но про типы там ничего не сказано. Да и сложно в таком формате еще и верные типы расставвить. А в примере с Ларавел - там чисто ДТО со статическим конструктором. Оно как раз нужно, чтобы из одного слоя программы (например, контроллера) передать данные в другой слой (например, сервис). И больше ничего. Поэтому я думаю, что даже если остальные методы в классе DO убрать - это все равно не будет ДТО, в первую очередь потому что класс абстрактный
это не DTO, это абстрактный класс с помощью которого можно сделать DTO вот например пакет для ДТОшек https://github.com/spatie/data-transfer-object посмотри блок Usage
То есть наследники \DigitalOceanV2\Entity\AbstractEntity и есть DTO? Например, этот: https://github.com/DigitalOceanPHP/Client/blob/292f1a6bb8d4f4e168661b7e3ba63a92e3a414e4/src/Entity/Tag.php
В этом пакете есть типы. А у ДО типов нет. С таким же успехом можно массивы использовать
if (\property_exists($this, $property)) { $this->$property = $value; }
сделай в своей DTO typed properties и автоматически появится проверка типов средствами PHP 7.4
Спасибо! Теперь ясно. Нужно было изначально мне вопрос поставить по другому: "является ли AbstractEntity фабрикой DTO" :) Есть еще один вопрос. Правильней будет сделать геттеры для свойств DTO, а свойства - private? DigitalOceanPHP/Client в клиентском коде получает эти свойства напрямую, а не геттерами (почему?). Ну, инкапсуляция там. Все дела
ну хз я считаю что DTO в простейшем виде это вот эти 3 строки в конструкторе и всё, а дальше это уже наворачивание магии
правильнее взять нормальный пакет для DTO, ссылку выше я дал, а это поделие от DO оставить самим DO
Даже название класса тебе намекает, что это не дто
Обсуждают сегодня