1. Enrutador de práctica de desacoplamiento modular del cliente

antecedentes

A medida que el negocio ha entrado en un período de rápido desarrollo, las líneas de negocio se han expandido rápidamente y la estructura del proyecto se ha vuelto enorme y compleja, lo que genera costos de iteración cada vez más altos. Cuanto mayor sea el tamaño del proyecto, también aumentará el tiempo de compilación de todo el proyecto. La operación modular (autooperación del proyecto, autogestión) después de que el proyecto se divide es una mejor salida, pero las complejas referencias mutuas entre proyectos hacen que sea imposible para nosotros comenzar, y cómo eliminar las referencias entre estos proyectos es el tema de hoy.

Produce

En primer lugar, podemos resolver la situación actual. El mayor problema que encontramos es en realidad el desordenado acoplamiento y cotización entre proyectos.

 

Con respecto a estos acoplamientos y dependencias, podemos simplemente analizar: En teoría, cada proyecto es responsable de un negocio separado y debería existir de forma independiente el uno del otro. Pero, de hecho, en el sistema de negocios de la misma empresa, es imposible lograr realmente una separación completa entre proyectos . (La cooperación puede existir entre empresas, y los proyectos y proyectos son, por supuesto, incluso más probables)

Parece que es imposible eliminar las dependencias comerciales del origen del negocio, solo podemos hacer el acoplamiento entre proyectos y la eliminación de referencias desde nuestro punto de vista técnico. Y el punto más crítico es: el acoplamiento, la interdependencia , y se plantea el concepto de Router para solucionar estos problemas.

Entonces, ¿qué es exactamente el enrutador?

El enrutador es un modelo con idea de cierre y distribución , que se utiliza para lidiar con dependencias directas y llamadas entre módulos (proyectos). La manifestación más directa es en realidad un acuerdo y una regla, que se analiza de acuerdo con el acuerdo y las reglas , y luego se distribuye.

 

desarrollo de

En vista de algunos de los problemas anteriores, podemos obtener algunas características clave, cerrar la boca y distribuirlas .

Bien, ahora que se ha obtenido la información clave, el pseudocódigo se puede escribir pronto:

 

    public static void jump(String rule){
        if(rule){
            gotoBusinessActivity()
            return;
        }
    
        if(rule){
            invokeBusinessFunction();
            return;
        }
    }

Perfecto !!! llamada fácil, realmente se cerró , distribución

Pero con el desarrollo del negocio, las deficiencias se han vuelto cada vez más obvias. Después de un análisis cuidadoso, se pueden resumir algunos problemas

Hinchar

• Con el crecimiento del negocio, la expansión es demasiado grande, miles de líneas de código se ubican en esta categoría, una verdadera mezcolanza

Costo de mantenimiento

• Todos los proyectos se mantienen al mismo tiempo, y la corrección de un proyecto puede hacer que otros proyectos también se vean afectados.
• if-elseEl mantenimiento de la lógica es demasiado complicado
• La lógica de distribución es hardcode , una vez que ocurre un error, no se puede modificar
• Los proyectos no se pueden separar verdaderamente

Expandir

• A partir de la estructura del código, no es difícil ver que la distribución aquí es esencialmente " práctica" y no una distribución real , y que la " práctica" no puede lograr una división real.

A juzgar por las preguntas anteriores, no es difícil cerrar la boca , pero cómo distribuirlo es una tarea difícil.

Mirando hacia atrás en los requisitos y los problemas existentes, siento que mi if-elsemodelo en realidad ha perdido una cosa: no saqué un proceso unificado.

¿Cómo definir el proceso?

Cuando diseño, me gusta comparar con la vida real, y Router no es más que. Y este modelo es muy interesante

Quiero enviarlo por mensajería

Este es mi requisito, entonces, ¿qué debo hacer? Los dos puntos mas importantes

1. dirección
2. paquete

Solo necesito dar la dirección del mensajero y el paquete , luego me lo entregarán (a menos que la dirección sea incorrecta), pero quiero enfatizar que estoy enviando un mensajero y no es un mensajero para aceptar el paquete. El mensajero solo entrega , y la persona en la dirección realmente lo recibe .

Pensando en esto, realmente puede ordenar el ciclo de vida central y el ciclo de vida no central del enrutador . Cuando el enrutador transmite la intención del llamante al receptor , este ha completado su ciclo, lo siguiente es que el receptor lo hace y no tiene nada que ver con el enrutador .

 

 

En este punto, de hecho , se ha determinado el marco básico de Router (porque se ha separado el proceso), luego el resto es cuestión de módulos específicos. No es difícil analizar los dos módulos centrales de Router : procesamiento de reglas y ejecutor

regla

Por modelo, necesitamos saber dos cosas: la dirección , el paquete , que corresponde al programa no es más que el punto de destino , los datos , y luego encajar en nuestro escenario comercial actual, la regla no es difícil de extraer:

protocolo: // ruta? datos

¿No te resulta familiar? De hecho, es una versión simplificada de nuestra URL universal . De hecho, la atención se centra en tres piezas de información:

1. Protocolo, utilizado para distinción de versiones, distinción de funciones, etc.
2. Punto de destino, camino, destinatario de la intención
3. Datos

Del mismo modo, nuestra regla se define como

tctclient: // proyecto / módulo? clave = valor

La definición del protocolo está completa, pero la dificultad se acerca: cómo lidiar con el mapeo de Path

Por ejemplo, Path es hotel/list, pero esto es solo una cadena, realmente quiero llamar a la lista de hoteles HotelListAction, cómo sería Path y los asociados de orientación , esto es un problema. En el proceso de discusión, en realidad hay tres opciones:

1. if-else Asociación lógica directa
2. Usar Mapasociado
3. Utilice xml para la asociación

De hecho, en esencia, todos son iguales, todos para la asociación de datos. Pero existen diferencias en mantenimiento y expansión.

if-elseNo hace falta decir que la cotización directa generará una red de dependencias muy complicada , y es imposible extraer la distribución, todas las distribuciones deben estar asociadas en el entorno actual.

Map& XMLLógica como, son la ruta con la clase de tratamiento correspondiente. Pero en términos de mantenimiento y escalabilidad, finalmente elegimos xml , las ventajas son obvias: sin acoplamiento de código , actualización dinámica . La MAPventaja es que no se cargan datos, el rendimiento de esta parte del ahorro.

Solenoide

El concepto de ejecutor es mucho más fácil de entender. Después de analizar una regla en una intención legible, necesito pasar la intención y los datos al destinatario, y este destinatario puede ser manejado por varias empresas. Por lo tanto, necesito diseñar una interfaz (de lo contrario, no hay directividad) para recibir, y el departamento comercial puede procesar la lógica relacionada implementando esta interfaz.

 

Aunque el proceso básicamente ha terminado aquí, se derivará alguna lógica especial de la lógica empresarial real, como por ejemplo:

Quiero abrir la lista de hoteles, pero hay un requisito de que debo iniciar sesión antes de poder ingresar directamente; de ​​lo contrario, primero debo iniciar sesión.

Quizás solo desde el punto de vista de este requisito, no es difícil completarlo con el proceso actual, y se puede completar con dos receptores . Pero cuando hay una gran cantidad de lógica especial derivada en el medio y puede ser necesaria para varias empresas, el uso de dos (múltiples) receptores puede resultar muy inflado. En este momento, de hecho, surgió otro concepto: los interceptores .

Interceptador

Los interceptores son un procesamiento lógico general y especial que se realiza antes de que una regla tenga su efecto final .

La lógica de procesamiento es en realidad muy similar al evento View Touch . Cuando se genera un evento Touch , primero se asigna (distribuye) , luego se intercepta y finalmente se consume .

Y nuestro interceptor es ligeramente diferente

1. Puede haber varios interceptores
2. Solo cuando todos los interceptores estén satisfechos (pase) irá al ejecutor (consumo)
3. Este modelo de interceptor se puede implementar mediante recursividad

 

expandir

Para el marco de enrutador diseñado para usar hasta ahora más de dos años, las necesidades comerciales, también está básicamente completado, para satisfacer. De hecho, ha logrado la separación del marco del enrutador , la determinación del proceso y el mantenimiento de la lógica empresarial (incluida la relación de mapeo). Cuando surge un requisito comercial, solo es necesario generar una nueva regla para mantenerlo.

Sin embargo, al reexaminar el marco actual, todavía hay muchas cosas que deben mejorarse:

1. El mapeo de datos se asigna a través de xml, por lo que inevitablemente provocará I/Ola sobrecarga de rendimiento de la carga
2. Si la llamada al proyecto necesita escribir una regla muy larga, por ejemplo jump("tctclient://hotel/list"), y este tipo de parámetro de cadena generalmente no puede ser verificado por el compilador para verificar si es correcto o no.

Para estos dos problemas, en realidad usamos herramientas (plug-in) para completar.

Complemento de Gradle + Freemarker

El establecimiento de clases auxiliares en tiempo de compilación.

• La carga de xml puede generar directamente el mantenimiento de la relación del mapa en el momento de la compilación .
• Las reglas detalladas se pueden mantener mediante enumeración (la enumeración la genera xml) y el método de llamada se cambia ajump(Bridge.HOTEL_LIST)

para resumir

Este artículo trata más sobre mi viaje mental cuando recibí esta demanda. Todos tienen sus propios sentimientos al escribir código. De hecho, podemos encontrar mucha verdad en el diseño del enrutador.

No existe un modelo único para todos

Por ejemplo, al principio if-else, cuando el volumen de negocio es pequeño, esta puede ser una muy buena forma de afrontarlo. Cuando el negocio se expande y la estructura actual no es aplicable, es necesario reconstruirla a tiempo.

Si el marco está separado del negocio, no es nada, solo un marco que se ajuste al negocio es un buen marco.

Pensar es más importante que codificar

Cuando se recibe una demanda, es más pensar y diseñar. La clave para extraer el punto central, el proceso para el proceso de desentrañar el núcleo del ciclo de vida de la ciclo de vida no básico es muy importante

Autor: Sandking
Link: https: //www.jianshu.com/p/54d0e13dd7e3
Fuente: Los libros de Jane
tienen derechos de autor del autor. Para reimpresiones comerciales, comuníquese con el autor para obtener autorización, y para reimpresiones no comerciales, indique la fuente.