tutorial sirve requestmapping que para mvc modelandview formulario español ejemplo arquitectura java spring naming-conventions spring-mvc

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



spring mvc español (9)

Estoy atascado en descifrar 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. Entonces, por ejemplo, tengo la siguiente interfaz:

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

Y luego la clase de implementación ...

Lo que me molesta aquí es UserAccountManager es un buen nombre para la clase de implementación, así que me veo forzado a darle un nombre estúpido como SimpleUserAccountManager o UserAccountDbManager. ¿Cuáles son algunas de las convenciones que has usado 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 Manager sobre los nombres que terminan en Service?

Esto es lo que usamos:

  • XxxDAO (Objeto de acceso a datos) : responsable de interactuar directamente con EntityManager, JDBC DataSource, sistema de archivos, etc. Debe contener solo lógica de persistencia, como SQL o JPA-QL, pero no (o la menor cantidad posible) 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 UI. Debería hablar solo con los Servicios.
  • XxxUtilities / XxxUtils - Los métodos sin estado de Helper no deberían 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 agregamos el Sufijo Impl (XxxServiceImpl), para distinguirlo de la interfaz, y si hay varias implementaciones o si queremos agregar información adicional, la agregamos 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.

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 necesitamos / queremos modelar.

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

Lo que realmente importa suele ser mucho más básico que puntos tan finos: tener un modelo que todos los involucrados en el desarrollo comprendan bien. 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!

Para el ejemplo que das, usaría nombres de implementación que reflejen cómo la clase realiza las operaciones, como HibernateUserAccountManager, o JPAUserAccountManager, o JDBCUserAccountManager, etc., o quizás solo UserAccountManagerDAO.

Para mí, una clase de servicio se trata de 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".

Relacionado con la diferencia entre gerentes y servicios: yo diría que use una capa para la lógica de negocios (capa de servicio O capa de administrador) durante el mayor tiempo posible.

Tan pronto como esa capa se complica (suponiendo que utilizó servicios) puede agregar gerentes con la responsabilidad de delegar en un servicio u otro, pero mantener la lógica de negocios dentro de los servicios.

Así que mantendría los servicios simples, usaré gerentes para administrar servicios y mantendré la lógica comercial 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í.

Siento que el sufijo de nombramiento Service vs. Manager es puramente 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 en 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.

Spring da a las interfaces nombres genéricos y luego nombra las clases en función de 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 que nombres como SimpleUserAccountManager o UserAccountDbManager sean estúpidos, ya que transmiten cierta información sobre la implementación del administrador / servicio.

Lo que encuentro estúpido 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.

Suponiendo que se trata de servicios REST, creo que su convención de nomenclatura URI es más importante que el nombre de los servicios de implementación subyacentes, ya que este último será en gran medida invisible para los clientes. Por supuesto, quiere nombres consistentes internamente, pero no es tan crucial.

Algunas pautas de REST que hemos utilizado: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (mi blog)

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.