Мои классы обслуживания обычно имеют несколько переменных экземпляра ...
Это не обязательно запах кода.Если вашему сервису требуется много зависимостей для завершения своей работы, то это просто факт.
... они, похоже, выполняют большую работу (т.е. имеют много методов).
Желательно ли создавать более сфокусированные сервисы?
Как правило, чем более детализированны вы можете сделать свои сервис-интерфейсы (т.е. меньше методов), тем лучше (когда-либо приходилось тралить)через интерфейс с пятьюдесятью методами поиска того, который вы хотите вызвать?).Но если вы не выпускаете в качестве публичного API, гранулярность ваших сервисных интерфейсов может быть улучшена по мере продвижения.Часто, когда я запускаю проект, я начинаю с одного сервиса и делю его со временем.Если вы являетесь потребителем этих услуг, то, когда вы начнете чувствовать боль от расширения интерфейса, вы поймете, что пришло время его разбить.Конечно, если является публичным API, то вам придется сделать намного больше предварительного проектирования.
Кроме того, классы обслуживания должны хранить переменные экземпляра для других объектов?Я читал кое-что о службах, не имеющих состояния, и я не уверен, нарушаю ли я это правило, имея эти переменные экземпляра.
Хранение зависимостей как переменных экземпляра не обязательно означает, что ваш сервис не является состоянием без состояния,пока переменные экземпляра также не сохраняют состояния.Чтобы считаться не сохраняющими состояние, вызовы методов для службы никоим образом не должны зависеть от того, что были вызваны предыдущие методы.Вы должны иметь возможность загружать один экземпляр службы и предоставлять его для вашего приложения (т. Е. Экземпляр службы без сохранения состояния не должен быть специфичным для сеанса конкретного пользователя).Другими словами, ваш сервис не должен поддерживать никакого состояния между вызовами методов.Хранение зависимости хранилища без сохранения состояния в качестве переменной в экземпляре службы не нарушает это требование.
Причина, по которой службы без сохранения состояния являются желательной целью, отсутствие состояния значительно уменьшает вероятность ошибок.Это упрощает тестирование метода службы, ограничивая тестовые случаи изменением переданных параметров, вместо того, чтобы беспокоиться о предыдущем состоянии службы.Это также может предложить преимущества производительности.