Какое соглашение об именах вы используете для уровня обслуживания в приложении Spring MVC?

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

public interface UserAccountManager{
   public void registerUser(UserAccount newUserAccount);
   public void resetPassword(UserAccount userAccount);
...
}

И затем класс реализации...

Какие ошибки меня здесь, UserAccountManager - хорошее имя для класса реализации, поэтому я вынужден указывать ему глупое имя, например SimpleUserAccountManager или UserAccountDbManager. Каковы некоторые из конвенций, которые вы использовали до сих пор? Является ли хорошей идеей поставить классы реализации в другой пакет и дать им те же имена, что и интерфейсы? И каковы ваши мысли об использовании имен, заканчивающихся в Менеджере над именами, заканчивающимися Сервисом?

Ответ 1

Spring сам предоставляет интерфейсы общие имена, а затем имена классов, основанные на деталях реализации. Это один из примеров, который приходит в голову:

interface: Controller
abstract classes: AbstractController, AbstractCommandController, 
                  SimpleFormController, MultiActionController

Я не думаю, что такие имена, как SimpleUserAccountManager или UserAccountDbManager, являются глупыми, поскольку они передают некоторую информацию о реализации менеджера/службы.

То, что я считаю глупым, является общим соглашением о добавлении суффикса "Impl" в классах реализации:

my/package/UserAccountManager
my/package/impl/UserAccountManagerImpl

Некоторые люди предпочитают это, хотя.

Ответ 2

Вот что мы используем:

XxxDAO (объект доступа к данным) - Ответственный за непосредственное взаимодействие с EntityManager, JDBC DataSource, файловой системой и т.д. Должен содержать только логику сохранения, такую как SQL или JPA-QL, но не (или как можно меньше) бизнес-логику. Должен быть доступ только от менеджеров.
XxxManager - Управляет полномочиями на уровне бизнеса, обычно выполняет операции CRUD, но добавляет требуемую бизнес-логику.
XxxService - Уровень, на котором находится бизнес-логика. Должен "говорить" в простых объектах - Строках, ints и т.д. - насколько это возможно.
XxxController - Уровень взаимодействия пользовательского интерфейса. Следует говорить только о службах.
XxxUtilities/XxxUtils - Вспомогательные методы без сохранения, не должны зависеть от какой-либо службы в системе. Если вам нужно такое выделение, либо преобразуйте класс утилиты в службу, либо добавьте результат службы в качестве параметра.

Для реализации мы добавляем Suffix Impl (XxxServiceImpl), чтобы отличить его от интерфейса, а если есть несколько реализаций или мы хотим добавить дополнительную информацию, мы добавляем его как префикс (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl и т.д.). Названия классов становятся немного длинными, но они очень описательны и самодокументированы.

Ответ 3

В приведенном примере я бы использовал имена реализации, которые отражают, как класс выполняет операции, такие как HibernateUserAccountManager или JPAUserAccountManager, или JDBCUserAccountManager и т.д., или, возможно, просто UserAccountManagerDAO.

Ответ 4

Это, очевидно, не важно само по себе, заканчиваются ли имена классов в Менеджере или Сервисе. Важным, вообще говоря, является то, что имена точно передают то, что моделируется. И что суть проблемы: "Услуги" или "Менеджеры" - это не объекты реального мира, которые мы пытаемся моделировать в наших программных объектах. Скорее, это места, где мы собираем множество методов, которые делают вещи, которые просто не вписываются в обязанности любого из объектов, которые нам нужны/хотят моделировать.

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

Что действительно важно, как правило, гораздо более основательно, чем такие тонкие моменты: иметь модель, которая хорошо понятна всем, кто участвует в разработке. Если мой опыт - это что-то, что можно сделать, это редко бывает. Мой совет тем, кто спрашивает, является ли "менеджер" или "сервис" правильной метафорой, таков: переверните монету, убедитесь, что все знают об этом соглашении, и тратите свое время на размышление и обсуждение важных вопросов!

Ответ 5

Я чувствую, что суффикс имен имен "Сервис" или "Менеджер" является исключительно предпочтительным. Единственный раз, когда "Сервис" когда-либо вызывал путаницу для нас, - это когда у нас также есть веб-службы, сидящие поверх нашего уровня обслуживания. В некоторых проектах мы просто ссылались на классы веб-сервисов как на брокеров, так как все, что они делали, было для перевода или брокера вызова веб-службы в призыв к нашему уровню обслуживания.

Я согласен с kgiannakakis, что суффикс ваших реализаций с помощью "Impl" не является хорошим подходом. Я также сталкивался с передовыми методами кодирования, которые упоминают, что не нужно это делать. Именование интерфейса после абстракции является общепринятой лучшей практикой. Именование класса реализации после интерфейса с некоторым индикатором его цели или типа, как предположил kgiannakakis, является общепринятым подходом.

Когда у нас есть DAO на основе веб-сервисов и DAO на основе ORM, мы используем как пакеты, так и имена классов, чтобы различать классы реализации от их интерфейсов и друг от друга. Я думаю, что реализация реализаций в разных пакетах сводится к тому, сколько классов у вас есть в пакете, как они реализованы по-разному и сколько вы хотите разделить.

Ответ 6

Вы также можете назвать интерфейс IUserAccountManager (например, это соглашение используется в Eclipse RCP), а затем использовать UserAccountManager для реализации по умолчанию.

Ответ 7

Для меня класс обслуживания - это реализация прецедента, поэтому я называю его в соответствии с тем, какой пользователь услуга действует от имени. Поэтому, если у меня есть приложение с разными ролями, скажем, клиенты, пользователи Fullfillment Order, люди ввода данных и админы, тогда у меня, скорее всего, есть CustomerService, OrderFulfillmentService, DataEntryService и AdminService. Я думаю, что присвоение имен службе в соответствии с типом данных, которые выбраны или спрятаны, является анти-шаблоном. Поэтому, предполагая, что манипуляция UserAccount будет областью администратора, я бы назвал ее "AdminService".

Ответ 8

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

Некоторые рекомендации REST, которые мы использовали: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (мой блог)

Ответ 9

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

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

Таким образом, я бы упростил обслуживание, использовал менеджеров для управления службами и поддерживал бизнес-логику внутри служб.

Я также согласен с тем, чтобы исключить суффикс Impl для реализации и избежать суффикса я для интерфейсов. Например, для меня лучше звучит название интерфейса "Контроллер" и называние реализации "SimpleController" или "UserController".