¿Qué convención de nomenclatura usa para la capa de servicio en una aplicación Spring MVC?

Question

Estoy atascado con la idea de una buena convención de nombres para la capa de servicio en una aplicación de primavera. Para cada clase en la capa de servicio, primero escribo la interfaz que debe implementar y luego la clase real. Así, por ejemplo, tengo la siguiente interfaz:

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

Y entonces la clase de implementación ...

Lo que me molesta aquí es UserAccountManager es un buen nombre para la clase de implementación por lo que me veo obligado a darle un nombre estúpido como SimpleUserAccountManager o UserAccountDbManager. ¿Cuáles son algunas de las convenciones que ha utilizado hasta ahora? ¿Es una buena idea poner las clases de implementación en un paquete diferente y darles los mismos nombres que las interfaces? ¿Cuáles son sus pensamientos sobre el uso de nombres que terminan en Administrador sobre los nombres que terminan en Servicio?

Answer 1

Spring sí mismo da nombres genéricos a las interfaces y luego nombra las clases según los detalles de la implementación. Este es un ejemplo que viene a la mente:

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

No creo nombres como SimpleUserAccountManager o UserAccountDbManager son estúpidos, ya que transmiten una información relativa a la aplicación del administrador/servicio.

Lo que me parece estúpida es la convención común para agregar el sufijo "Impl" en las clases de implementación:

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

Algunas personas prefieren esto, sin embargo.

Answer 2

siento que el servicio vs Administrador de nombres sufijo es meramente una preferencia. El único momento en el que el "Servicio" nos ha causado confusión alguna vez es cuando también tenemos servicios web que se encuentran en la parte superior de nuestra capa de servicios. En algunos proyectos, simplemente nos referimos a las clases de servicios web como intermediarios, ya que todo lo que hicieron fue servir para traducir o intermediar la llamada de servicio web en una llamada a nuestro nivel de servicio.

Estoy de acuerdo con kgiannakakis que el sufijo de sus implementaciones con "Impl" no es un buen enfoque. También me he encontrado con las mejores prácticas de codificación que mencionan no hacer esto. Nombrar la interfaz después de la abstracción es la mejor práctica generalmente aceptada. Nombrar la clase de implementación después de la interfaz con algún indicador de su propósito o tipo, como sugirió kgiannakakis, parece ser el enfoque generalmente aceptado.

Cuando tenemos DAO basados ​​en servicios web y DAO basados ​​en ORM, utilizamos tanto paquetes como nombres de clases para diferenciar las clases de implementación de sus interfaces y entre sí. Creo que poner las implementaciones en diferentes paquetes se reduce a la cantidad de clases que tiene en el paquete, qué tan diferentes se implementan y cuánto desea dividir las cosas.

Answer 3

Para el ejemplo que das, me gustaría utilizar nombres de implementación que reflejan cómo la clase realiza las operaciones, como HibernateUserAccountManager o JPAUserAccountManager o JDBCUserAccountManager, etc, o tal vez sólo UserAccountManagerDAO.

Answer 4

También podría nombrar la interfaz IUserAccountManager (esta convención se usa en Eclipse RCP, por ejemplo) y luego usar UserAccountManager para la implementación predeterminada.

Answer 5

Aquí es lo que usamos:

• XxxDAO (Data Access Object) - responsable de interactuar directamente con el EntityManager, origen de datos JDBC, sistema de archivos, etc. debe contener sólo la lógica de persistencia, tales como SQL o JPA-QL, pero no (o tan poco como sea posible) la lógica comercial. Solo se debe acceder desde los gerentes.
• XxxManager - Administra las entidades a nivel comercial, por lo general realiza operaciones CRUD, pero agrega la lógica comercial requerida.
• XxxService - La capa donde reside la lógica de negocio. Debe "hablar" en objetos simples - Cuerdas, ints, etc. - tanto como sea posible.
• XxxController - La capa de interacción de la interfaz de usuario. Debería hablar solo con los Servicios.
• XxxUtilities/XxxUtils - Los métodos auxiliares sin estado, no deben depender de ningún servicio en el sistema. Si necesita dicha dependencia, convierta la clase de utilidad en un servicio o agregue el resultado del servicio como parámetro.

Para la implementación se añade el sufijo Impl (XxxServiceImpl), que se diferencia de la interfaz, y si hay varias implementaciones o que quieren añadir información adicional se añade como prefijo (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl, etc.) Los nombres de las clases se vuelven un poco largos de esta manera, pero son muy descriptivos y auto documentados.

Answer 6

Obviamente no es importante en sí mismo si los nombres de clase terminan en Administrador o Servicio. Lo que es importante, en términos generales, es que los nombres transmitan con precisión lo que se está modelando. Y ese es el quid del problema: "Servicios" o "Administradores" no son objetos del mundo real que intentamos modelar en nuestros objetos de software. Más bien, son lugares donde recopilamos un montón de métodos que hacen cosas que simplemente no encajan con las responsabilidades de ninguno de los objetos que do necesitamos/queremos modelar.

Personalmente prefiero el "servicio", pero solo porque "gerente" parece ser algo que uno realmente podría modelar, es decir, podría haber gerentes del mundo real que representen nuestros objetos "-manager". Pero el punto es completamente académico e inmediatamente acepto que no hace ninguna diferencia práctica en absoluto.

Lo que realmente importa es usualmente mucho más básico que puntos tan finos: tener un modelo que sea bien entendido por todos los involucrados en el desarrollo. Si mi experiencia es cualquier cosa, rara vez es el caso. Mi consejo para aquellos que preguntan si "gerente" o "servicio" es la metáfora correcta es por lo tanto: ¡Lanza una moneda, asegúrate de que todos conozcan la convención y dedícate tu tiempo a reflexionar y debatir sobre asuntos importantes!

Answer 7

Para mí, una clase de servicio consiste en implementar un caso de uso, así que lo nombro de acuerdo con el tipo de usuario por el que actúa el servicio. Por lo tanto, si tengo una aplicación con diferentes funciones, por ejemplo Clientes, Personas de Cumplimiento de pedidos, Personas que ingresan datos y Administradores, entonces probablemente tenga un Servicio al cliente, un Servicio de cumplimiento de pedidos, un Servicio de entradas de datos y un Servicio de administración. Creo que nombrar un servicio de acuerdo con el tipo de datos que se buscan o mezclan es un anti-patrón. Así que adivinando que la manipulación de cuentas de usuario sería el dominio de un administrador, probablemente lo llamaría "AdminService".

Answer 8

Asumiendo que estos son para los servicios REST, creo que su convención de nombres URI es más importante que el nombre de los servicios de implementación subyacentes, ya que esta última será en gran medida invisibles a los clientes. Por supuesto, quiere nombres consistentes internamente, pero no es tan crucial.

Algunas pautas resto lo han utilizado: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (mi blog)

Answer 9

relacionada con la diferencia entre los gestores y servicios: yo diría que el uso de una capa de la lógica de negocio (capa de servicio o capa manager) durante el tiempo como sea posible.

Tan pronto como esa capa se complica (suponer que utilizó los servicios) se puede añadir a los administradores la responsabilidad de delegar a un servicio u otro, pero mantener la lógica de negocio dentro de los servicios.

Así que mantendría los servicios simples, usaría gerentes para administrar servicios y mantendría la lógica de negocios dentro de los servicios.

También estoy de acuerdo con evitar el sufijo de Impl para las implementaciones y evitar el sufijo I para las interfaces. Como ejemplo, nombrar la interfaz "Controlador" y nombrar la implementación "SimpleController" o "UserController" suena mejor para mí.