Что такое Service Object?

Service Objects (или services) – подразумевает создание

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

Для чего нужен Service Object?

Service Object полезен в коде, когда нам нужно место для
создания каких-то сложных действий, процессов с большим
количеством шагов и для взаимодействий с несколькими
моделями сразу. Существует несколько проблем при которых
Service Object может облегчить нам жизнь:

Первая Проблема
Контроллеры и модели разрастаются. Количество строк кода
в одном файл может вырасти до нескольких тысяч

Вторая Проблема
Непонятно, где искать код, в модели или в контроллере.

Третья Проблема
Невозможно или затруднительно протестировать отдельные
участки кода контроллера, через консоль или через
автоматические тесты
 Как получить максимальную выгоду от Service Object?

1. Придерживаетесь одной конвенции имен

Service Object можно именовать по разному. Кто-то

использует для этого суффикс ‘Service’. Кто-то использует
суффикс ‘or ’

Поэтому надо выбрать какой-то один и всегда

придерживаться его в проекте.

2. Service должен быть объектом

Service должен быть экземпляром класса. Это позволит

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

Данный принцип не означает, что все параметры нужно

передавать в конструктор. Передавайте в конструктор
информацию о контексте исполнения, которая вряд ли будет
изменяться с течением времени в рамках выполнения одного
запроса, например — текущий пользователь
 3. Service Object должен отвечать только за одно
действие

Service Object – это единичные business actions. В Service

Object должен быть только один публичный метод для
выполнения строго определенного действия. Если сервис
выполняет несколько действий, то значит он:

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

данную проблему

При его изменении могут начаться конфликты при слиянии

исходного кода, если над проектом работает несколько
человек

4. Service Object должны быть простыми

Это хорошая идея, чтобы сохранить конструкторы простыми

и понятными, когда мы пишем их. Тем не менее, наш
основной способ вызова Service заключается в методе вызова
класса.

Также не мало важно сделать конструктор ответственным

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

Также мы должны понимать, что может находиться в

конструкторе, и тем, чего там не должно быть.

5. Надо делать аргументы метода Call проще

Если в Service Object находиться более одного аргумента,

можно сделать какие-то key word, чтобы сделать эти
аргументы более всеобъемлющими. Даже если service object
принимает только один аргумент, использование аргумента
key word делает код более читабельным, например
 6. Надо обрабатывать исключения

Обрабатывайте исключения внутри Service Object так чтобы

он всегда возвращал корректный стандартизированный
результат и не выбрасывал исключения. Это позволит писать
единообразный код при обращении с любыми сервисами.
 Какие должны быть возвращаемые значения Service
Object?

Есть несколько вариантов, в каком виде можно возвращать

данные из сервиса, например:

1. Код результата
2. False в случае неудачи и данные в случае успеха
Но у каждого из этих вариантов есть свои особенности и
сложности:

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

2. False в случае не корректной работы service или

валидных данных в случае успеха
Service будет возвращение False в случае ошибки, а в случае
успеха валидных данных. Но в случае ошибки такой подход
делает затруднительным понимание, в связи с чем произошла
ошибка.

Но лучше всего использовать объект результата, так как он

может включать в себя все вышеперечисленные методы. В
таком объекте можно хранить код успешной реализации, код
ошибки, если она произошла, и данные, которые мы хотим
получить. В таком случае исходного кода получается
немного больше, чем во всех остальных вариантах, однако
мы получаем больше информации, а также все сервисы
работают единообразно.
 Для чего не надо использовать Service Object?

1. Не создавать универсальные Service Object

Service Object это единичные бизнес действия, и мы должны

разбивать функциональность, так как если этого не делать, то
это будет идти вразрез с бизнес-логики. А если понадобиться
применить этот код для других business objects, то можно
создать модуль и его можно смешать с нашими service objects

2. Не выносите код Callback ActiveRecord в Service object,

если он не относится к бизнес логике

1. Удаление лишних пробелов в начале и в конце строк

2. Заполнение вспомогательных полей в таблице,

которые нужны для оптимизации запросов.

3. Не разбирайте параметры запроса в сервисе

Например, преобразовывайте строки в Object Data на уровне

контроллера и после этого передайте в service Object, потому
что параметры в Service Object будет мешать чтению кода и
будет сложно концентрации на алгоритме.