Capa de lógica empresarial Spring Boot

Acerca de la capa de lógica empresarial (capa de servicio)

La capa de lógica empresarial es la capa llamada directamente por el controlador (el controlador no permite llamadas directas a la capa de persistencia Generalmente). , en la capa de lógica empresarial, el código está escrito para garantizar la integridad y seguridad de los datos para que puedan generarse o modificarse según las reglas que establezcamos.

Por lo general, el código en la capa de lógica de negocios consta de interfaces y clases de implementación, donde la interfaz se considera obligatoria

El código en la capa de lógica de negocios es para garantizar la integridad de la datos y seguridad para que los datos se generen o cambien de acuerdo con las reglas que establecemos.

Por lo general, el código en la capa de lógica empresarial consta de interfaces y clases de implementación, donde las interfaces se consideran obligatorias

En cuanto a las excepciones lanzadas, suelen ser excepciones personalizadas. Las excepciones personalizadas suelen ser subclases. de `RuntimeException`.

A continuación, cree una excepción específica correspondiente a una determinada "falla". Por ejemplo, si falla al agregar un administrador porque el nombre de usuario ya existe, se crea una excepción `UsernameDuplicateException`:

Además, al insertar datos, si el número de filas afectadas devueltas no es 1, debe haber alguna Error, se creará una excepción `InsertDataException` en este momento:

En cuanto a los parámetros del método abstracto, deben diseñarse como el tipo de datos enviado por el cliente o el tipo de encapsulación correspondiente, en lugar del entidad correspondiente al tipo de tabla de datos! Si usa un tipo encapsulado, el tipo debe agregar algún tipo de sufijo después del nombre de la clase, como "DTO" u otro sufijo, por ejemplo:

Y cree el subpaquete "impl" bajo el paquete "servicio" anterior y luego cree la clase "AdminServiceImpl":

¡El código anterior no está implementado! ¡Cifrado de contraseña! Con respecto al cifrado de contraseñas, el código relevante debe definirse en otras clases y el proceso de cifrado no debe escribirse directamente en el código anterior, porque el código de cifrado debe aplicarse en varios lugares (agregar usuarios, iniciar sesión como usuario, cambiar contraseñas, etc.). .), desde la perspectiva de la división del trabajo. Mira, ¡esta no debería ser tarea de la capa de lógica empresarial! Por lo tanto, cree una clase `PasswordEncoder` en `cn.celinf.boot.demo.util` (el paquete no existe, créelo) para manejar el cifrado de contraseña:

Una vez completado, debe crear a `AdminServiceImpl` Ensamble automáticamente el `PasswordEncoder` anterior y llame al método `encode()` del objeto `PasswordEncoder` cuando se requiera cifrado.

Desarrollo de la capa del controlador

Spring MVC se utiliza para manejar el desarrollo de la capa del controlador. Al usar Spring Boot, puede integrar el marco Spring MVC y las dependencias comunes relacionadas (incluido `jjjb.xml`) agregando `spring-boot-starter-web` en `pom.xml`, y puede algo de `spring-boot -starter` se cambió a `spring-boot-starter-web`, porque `spring-boot-starter-web` ya contiene `spring-boot-starter`.

Primero, cree el subpaquete `controller` en el paquete raíz del proyecto y cree `AdminController` en este subpaquete. Esta clase debe agregar `@RestController` y ` @RequestMapping (valor). = "/admins", produce una anotación = "application/json; charset=utf-8")`, por ejemplo

Dado que se ha decidido que la respuesta del lado del servidor será una cadena en formato JSON, Para garantizar que pueda responder al resultado JSON, se debe personalizar el valor de retorno del método que maneja la solicitud. Para garantizar que podamos responder a los resultados JSON, el valor de retorno del método que maneja la solicitud debe ser un tipo de datos personalizado, por lo que encontramos la clase `JsonResult` y los tipos relacionados del proyecto `spring-mvc` que aprendimos. antes y los copié en el proyecto actual.

Una vez completado, ejecute la clase de inicio para iniciar todo el proyecto. `spring-boot-starter-web` contiene dependencias en Tomcat. Al inicio, el proyecto actual se empaquetará e implementará automáticamente en este Tomcat. entonces, cuando se ejecuta la clase de inicio, este Tomcat también se ejecutará al mismo tiempo, ya que el Tomcat integrado solo sirve para el proyecto actual, la ruta de contexto (por ejemplo: spring_mvc_warp_web_web... Por ejemplo, al implementar el proyecto. para Tomcat, spring_mvc_war_exploded está configurado como una cadena vacía de forma predeterminada, por lo que después de iniciar el proyecto, la URL a la que se accede no contendrá el valor de la ruta de contexto encontrada antes.

Después de que el proyecto se haya iniciado correctamente, puede escribir el. URL en la barra de direcciones del navegador. Para probar el acceso.

Nota: Si no se agrega la cuenta de administrador, la ejecución puede finalizar con éxito. Si la cuenta de administrador ya existe, se generará un error 500 porque. la excepción aún no se ha manejado

Luego, cree la clase "handler.GlobalExceptionHandler" en "cn.celinf.boot.demo.controller" para manejar las excepciones de manera unificada, por ejemplo:

Una vez completado, reinicie el proyecto y cuando agregue Cuando el nombre de usuario del administrador no esté ocupado, se agregará normalmente, y cuando el nombre de usuario esté ocupado, la respuesta se basará en el resultado del manejo de excepciones.

Debido al mecanismo unificado de manejo de excepciones, la misma excepción, sin importar en qué negocio ocurra, la descripción de la información de manejo de excepciones es exactamente la misma y el mensaje de error no se puede expresar con precisión. ¡Esto es inapropiado! Además, de acuerdo con la idea de "división del trabajo" orientada a objetos, el mensaje de error (descripción de la excepción) debe ser Lo describe el servicio, es decir, "quién lanza una excepción, quién describe la excepción", porque el fragmento de código que arroja la excepción es el fragmento de código que comprende mejor la causa de la excepción.

¡Para describir mejor! la causa de la excepción, debe agregar todos los constructores basados ​​en la clase principal (5) a la `ServiceException` personalizada y sus subexcepciones, y luego en `AdminServiceImpl`, cuando se lanza una excepción, puede agregar una `String ` escriba el parámetro en el constructor de la excepción para describir el motivo de la excepción, por ejemplo, el motivo por el que ocurrió la excepción.

Finalmente, al manejar una excepción, puedes llamar al método `getMessage()` del objeto de excepción para encapsular la descripción del mensaje en el lanzamiento, por ejemplo:

Después de completar , reinicie nuevamente el proyecto y podrá mostrar el mensaje de error descrito en el servicio cuando el nombre de usuario ya exista. ¡Mensaje de error descrito en el servicio!

Como puede ver, ya sea exitosa o fallida, la respuesta JSON contiene datos innecesarios (datos "nulos"). Estos atributos de datos no son necesarios para responder al cliente, si necesita eliminarlos. estos valores innecesarios, puede usar anotaciones para configurar las propiedades correspondientes, por ejemplo:

Esta anotación también se puede agregar a la clase y luego funcionará en todas las propiedades de la clase actual, por ejemplo:

p>

Incluso si se agrega a la clase, solo funciona en 3 atributos de la clase actual. Posteriormente, al responder a algunos datos, el atributo `datos` puede ser de tipo usuario, producto, pedido, etc., estos La parte "nula" en los datos del tipo aún será respondida en el lado del cliente. , por lo que estos tipos también requieren la misma anotación.

El método anterior es relativamente engorroso. Puede agregar una configuración global en `application.properties`/`application.yml`, que se aplica a todas las clases involucradas en la respuesta en el proyecto actual, por ejemplo, en `properties ` en:

Nota: Cuando necesite agregar la configuración anterior en `yml`, el prefijo no se usará en la respuesta, por lo que el prefijo se usará en la respuesta. Cuando necesite agregar la configuración anterior en `yml`, es posible que el nombre del atributo de prefijo ya exista. En este caso, no se permiten nombres de atributo de prefijo repetidos:

Finalmente, la configuración anterior es solo la "predeterminada". " configuración. Si algunos tipos aún requieren una configuración diferente, aún puede configurarla en una clase o propiedad a través de `@JsonInclude`.

15. Resolver problemas entre dominios

En el modelo de desarrollo donde el front-end y el back-end están separados, el proyecto front-end y el proyecto back-end pueden ser Dos proyectos completamente diferentes, y cada proyecto se desarrolló e implementó de forma independiente. El siguiente error:

La palabra clave del mensaje de error anterior es "CORS", que a menudo se denomina "problema entre dominios".

En proyectos basados ​​en el marco Spring MVC, cuando es necesario resolver problemas entre dominios, se necesita una clase de configuración Spring MVC (una clase de configuración que implementa la interfaz `WebMvcConfigurer`) y los métodos en se anula para permitir especificar el acceso entre dominios en condiciones, por ejemplo:

16. Formato de los parámetros de solicitud enviados en el lado del cliente

Generalmente, cuando el cliente envía una solicitud a en el servidor, los parámetros de solicitud pueden tener dos. El primero es empalmar parámetros y valores directamente a través de "amp;`", por ejemplo:

Qué forma usar depende del diseño del lado del servidor :

- Si la solicitud se procesa Si el método del lado del servidor agrega `@RequestBody` antes del parámetro, se permite utilizar el segundo método anterior (datos JSON) para enviar los parámetros de la solicitud, pero el El primer método anterior (usando empalme `amp;`) no está permitido

- Si no se usa `@RequestBody`, solo se permite la opción 1 anterior