Использование черт для сервисного уровня: это плохая практика?

Question

Использование черт для сервисного уровня: это плохая практика?

Я заметил, что программисты laravel часто используют черты для реализации своего рода внедрения зависимостей в контроллеры, а также сам laravel использует много черт для реализации чего-то, что мне кажется, сервисами.

Я родом из Symfony, где черты не очень широко используются в самой среде, и я нахожу это немного странным, так как нахожу использование черт по такой причине, а не из-за ясного дизайна. Разве услуги не должны быть определены в их собственных классах? Допустимо ли использовать черту для услуг?

2

dependency-injection laravel php software-design symfony

Решение

Другие решения

черта характера похож на абстрактный класс, который не может быть создан самостоятельно.

Traits — это механизм повторного использования кода в языках с одним наследованием.
в этом случае PHP.

Теперь, когда вы обнаружите, что ваша модель, например, становится слишком раздутой, и вы снова и снова используете одну и ту же функциональность в разных моделях, вы можете подумать, что это признак использования черты.

Теперь вы можете подумать, поскольку у нас одинаковая функциональность, почему бы не использовать шаблон шаблон дизайна вместо?! Однако, поскольку все модели в Laravel расширяют базовую модель, вам действительно следует быть осторожным с использованием промежуточных устройств.

Laravel по умолчанию использует много черт, например, если вы хотите использовать softDeletes() тогда вы просто тянете черту, чтобы внести функциональность в эту модель.

Вот практическое использование черты. В одном из моих приложений случается, что я хочу отслеживать все обновления, которые происходят в моей базе данных, и сохранять их в другой таблице. Поэтому, если я хочу отслеживать активность модели, я просто использую эту черту:

<?php

namespace App;

use App\Activity;

trait RecordsActivity
{

protected static function bootRecordsActivity()
{

static::created(function ($thread) {
$thread->recordActivity('created');
});
}

protected function recordActivity($event)
{
Activity::create([

'user_id'      => auth()->id(),
'type'         => $event . '-' . strtolower((new \ReflectionClass($this))->getShortName()),
'subject_id'   => $this->id,
'subject_type' => get_class($this),
]);
}
}

Поэтому, когда я хочу отслеживать модельную деятельность, я просто использую эту черту,

use RecordsActivity;

вместо того, чтобы раздуть модель с помощью дополнительного кода и даже худшего кода в разных моделях, или сделать его более спагетичным, используя наследование классов.

Или в некоторых встроенных чертах в Laravel, когда они вам нужны, например, softDeletes, вы просто должны вставить их, вместо того, чтобы подготовить их в базовом классе, даже если они вам не нужны.

0

Источник

Accepted Answer

Я заметил, что предыдущий ответ еще не был принят, поэтому я подумал дать свои 2 цента.

Придя также из среды Symfony 2, будучи связанным с Laravel в настоящее время и готовясь к среде Symfony 3, я также читал эту тему, поскольку я читал, что черты являются злом. Следующая ссылка имеет принятый ответ, который, на мой взгляд, не так уж субъективен, он делает некоторые справедливые предположения и выглядит хорошо сконструированным: https://codereview.stackexchange.com/questions/74077/trait-accessing-variables-of-classes-using-it

Тем не менее, я думаю, что самым большим отличием для вас может быть то, что Laravel по умолчанию использует ActiveRecord, в отличие от наличия слоев Service / Repository, которые используются Symfony. Я лично предпочитаю последнее, оно менее тяжелое, облегчает быть твердым, логика и данные чаще уже разъединены, что облегчает смену слоев. Во всяком случае, это не очень тематическая и очень личная заметка.

После работы в Laravel в течение нескольких месяцев (для сравнения, я годами работал в sf2 (и sf1)), я едва ли разбираюсь в том, как работает Laravel. Лично мне все еще не нравятся черты, потому что они кажутся мне слишком волшебными, если вы, по крайней мере, не взаимодействуете с ними. Я часто думаю, что лучше справляться с другими шаблонами дизайна.

TL; DR: (суть ссылки в основном)

Хорошим вариантом использования для черты является горизонтальное масштабирование, поддерживающее действия, которые стоят сами по себе, без лишних затрат на необходимость реализации его каждый раз, когда добавляется интерфейс. (обычно это довольно простая логика)
Плохая черта — это черта, которая использует информацию вне своей области видимости (например, свойства основного объекта или просто глобальное состояние) или принудительно / нарушает контракты.

4