Как должна быть моя подпись метода обслуживания?

Question

Я использую Service Layer, и до сих пор я использовал ServiceObject (который реализует ArrayAccess, Iterator, Countable), но мне интересно, если это хорошие идеи.

Вы бы сделали:

ArticleService::createArticle($articleData, $userId);

или

ArticleService::createArticle(ServiceObject $data);

, где $data:

array(
  'title' => 'Lorem ipsum',
  'body'  => 'Dolor sid amet',
  'userId' => 55,
);

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

Есть ли какие-либо отзывы?

Answer 1

Измените его на:

ArticleService::createArticle($title, $body, $user_id);

Это очень ясно дает понять, что вам нужно для создания массивов 'Article'.

'option', таких как $articleData и $dataневозможно разумно осмыслить, и я бы посоветовал против этого.

Отбрось свою идею об общем ServiceObject это на самом деле очень плохая идея.Ваши мотивы благородны, но это неправильное решение.

Если вам нужно больше убедительности, не стесняйтесь тыкать.

Answer 2

Я думаю, что лучшим подходом здесь было бы иметь что-то вроде

$article = new Article;
$article->title = "Lorem ipsum"
$article->body = "Dolor sit amet"
$article->creator = $userID
ArticleService::createArticle($article)

Хотя предположительно «createArticle» больше не будет лучшим именем для функции, поскольку объект Article уже создан.Возможно, у вас есть что-то вроде ArticleService::publishArticle($article), хотя я не знаю, что вы делаете.

Вам нужно отделить конструкцию ваших данных (Article) от их использования (* 1008)*).

Что я на самом деле пытаюсь сказать, так это не превращайте аргумент createArticle в общий массив или «ServiceObject», оба из которых являются бесполезными абстракциями списков аргументов, делайте его классом, который действительно представляет соответствующиеюридическое лицо.

Answer 3

Я думаю, что лучший подход - это инъекция объекта. Но почему там ServiceObject? У вас есть метод createArticle, тогда было бы логично передать ему объект article, нет? Таким образом, проще организовать процесс проверки, вы можете просто отметить поля, которые вы хотите проверить в аннотациях.

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

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

Answer 4

Не существует правильного пути , но я бы использовал ArticleService::createArticle($articleData, $userId); в данном конкретном случае.

Я предполагаю, что статья имеет обязательное непустое свойство userId (которое вы получаете из контекста) и необязательные (не очень важные) данные содержимого, которые могут быть пустыми.

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

Как доказательство: мгновенно, когда я увидел ArticleService::createArticle($articleData, $userId), я понял, что делает метод и что ожидает от входных данных, а второй удивил меня.

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

С другой стороны, в ZF достаточно часто использовать массивы в качестве параметров, чтобы ваш код мог выглядеть в другом стиле.

Однако это в основном зависит от ваших предпочтений.

Answer 5

Второй способ лучше , у вас никогда не возникнет проблем с людьми, которые неправильно называют ваш метод! Также намного легче читать и видеть то, что требуется. Для меня как разработчика было бы ясно, что я должен передать объект типа ServiceObject, а затем я начинаю искать документацию или пример или интерфейс этого класса. Но в первом примере я должен прочитать код createArticle, чтобы выяснить, как будут обрабатываться оба параметра.

Второй подход также поможет вам поддерживать чистоту вашего API / подписи с течением времени. Когда внутри createArticle требуются дополнительные данные, вы просто передаете их через ServiceObject и вам не нужно менять подпись!

Немного лучшая подпись для первого примера:

ArticleService::createArticle(array $articleData, $userId);

В этом случае $articleData должен быть массивом. Это предотвращает ошибки. В параметрах функции PHP для преобразования могут использоваться только массивы и имена классов.

Answer 6

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