Red de conocimiento informático - Aprendizaje de programación - ¿Qué hacer si la estructura de la tabla Java no es razonable y no puede cumplir con los nuevos requisitos?

¿Qué hacer si la estructura de la tabla Java no es razonable y no puede cumplir con los nuevos requisitos?

Arquitectura Java:

Como concepto, la arquitectura de software se refleja tanto en aspectos tecnológicos como comerciales.

Desde una perspectiva técnica: La arquitectura de software actualiza continuamente su contenido con innovaciones tecnológicas. La arquitectura de software se basa en la tecnología actual y en algunos principios básicos.

Hablemos primero de algunos principios básicos:

Principio de estratificación: la estratificación es una idea clave que se utiliza para reducir la profundidad y la complejidad del software. Así como la sociedad tiene clases, el software tiene jerarquía.

Principio de modularización: la modularización es un medio inevitable para resolver la amplitud y complejidad del software. El propósito de la modularización es permitir que el software divida el trabajo.

Con la mejora continua de la modularización del software, el principio de separación de la implementación de la interfaz y la programación orientada a la interfaz en lugar de la programación orientada a la implementación puede permitir que un software cada vez más complejo reduzca el acoplamiento entre módulos, haciendo así que cada módulo sea más flexible Mejorar fácilmente. Partiendo de este principio, el software también se ha estandarizado cuidadosamente desde una perspectiva micro.

Hay dos principios más pequeños pero muy importantes:

El principio de ocultación de detalles obviamente simplifica problemas complejos y oculta detalles feos, lo que puede hacer que la estructura del software sea más clara. De hecho, este principio se usa con mucha frecuencia. El principio de encapsulación en el lenguaje Java/C++ y el modo Fachada (apariencia) en el patrón de diseño pueden encarnar el espíritu de este principio.

Principio de inversión de dependencia Con el mayor desarrollo de la estructura del software, la dependencia entre capas y módulos se ha profundizado gradualmente, y los requisitos de conectabilidad dinámica de capas y módulos han aumentado sin razón. El principio de inversión de dependencia puede verse como una profundización del principio de separación de implementación de interfaces. Según el espíritu de este principio, el software ha entrado en la era de las herramientas. Este principio es algo similar a la conocida regla de Hollywood: no nos llames, nosotros te llamaremos.

Los principios anteriores establecen los indicadores de valor de nuestra arquitectura de software. Pero, después de todo, la arquitectura del software se basa en la tecnología actual. Y cada generación de tecnología tiene patrones arquitectónicos. No hablemos más del pasado. Echemos un vistazo a las tecnologías populares actuales y las arquitecturas que podemos adoptar actualmente.

Porque la orientación a objetos es actualmente la tecnología de desarrollo más popular, y el uso extensivo de patrones de diseño ha hecho que la orientación a objetos madure, y la base de datos es actualmente la estructura de almacenamiento más efectiva, y la interfaz web es actualmente la interfaz de usuario más popular. Por lo tanto, la arquitectura de tres capas más típica actual se basa en las tecnologías anteriores, utilizando la base de datos como capa de almacenamiento, la orientada a objetos para implementar la capa empresarial y la web como capa de interfaz de usuario. Comencemos con la arquitectura de tres niveles:

Debido a que la tecnología orientada a objetos y la tecnología de base de datos no son compatibles, agregamos una capa de persistencia de datos a la arquitectura estándar de tres niveles para administrar el mapeo bidireccional O-R, pero hay Actualmente no existe una tecnología de implementación óptima. Las tecnologías cmp y entidad bean están a punto de ser eliminadas debido a su compleja implementación y sus limitadas perspectivas funcionales. JDO e hibernación son los últimos en llegar al mapeo o, especialmente hibernación, que tiene funciones bastante completas. Recomendado como primera opción para la capa de persistencia

En la capa empresarial, debido a que el negocio actual está cada vez más cargado y cambia con frecuencia, debemos tener una tecnología lo suficientemente ágil para asegurar nuestra capacidad de adaptarnos a los cambios en el estándar. Sistema j2ee, sesión El bean es responsable del procesamiento comercial y tiene un buen rendimiento. Sin embargo, el uso del sistema ejb cambia demasiado el modelo de arquitectura comercial, es complejo y costoso y tiene poca portabilidad del código comercial. Spring, como arquitectura liviana para la configuración de beans y una hermosa implementación del modo IOC, tiene poco impacto en la arquitectura empresarial, por lo que se recomienda como marco empresarial de nivel medio.

En la capa de estructura del usuario, aunque servlet/jsp/jstl/javaBean puede implementar la arquitectura MVC, después de todo es demasiado tosco. La implementación de Struts de la arquitectura MVC es relativamente perfecta. Taperstry también implementa muy bien la arquitectura MVC y adopta un enfoque basado en eventos, que es muy atractivo, pero aún no está lo suficientemente maduro como infraestructura de capa de interfaz de usuario. .

Debido a que la capa empresarial es la más decisiva de la arquitectura de tres niveles, volvamos a la capa empresarial y analicémosla en detalle. En empresas complejas, a menudo necesitamos uno o más de los siguientes servicios básicos. : Servicio de coherencia de transacciones ácido (herramienta:jta/jts), servicio de bloqueo concurrente&&lock, caché del servicio de administración de grupos, servicio de control de acceso (herramienta:jaas), flujo de trabajo del servicio de control de procesos, servicio de implementación dinámica IOC, servicio de mensajes en serie (herramienta:jms) , servicio de equilibrio de carga, etc. Si no utilizamos servidores de aplicaciones pesados ​​(como weblogic, websphere, jboss, etc.) y componentes pesados ​​(EJB), debemos implementar algunos de estos servicios nosotros mismos. Aunque en la mayoría de los casos no necesitamos todos estos servicios, no es fácil implementarlos. Afortunadamente, tenemos una gran cantidad de código de implementación de código abierto, pero adoptar código fuente abierto a menudo no es una tarea fácil.

A medida que xml se vuelve cada vez más importante como transmisión y almacenamiento de información estructurada, el uso de algunas herramientas de manipulación de documentos xml (DOM, Digester, SAX, etc.) se vuelve cada vez más importante, y con la herramienta de enlace java del esquema xml (JAXB). Existe una tendencia creciente a utilizar xquery como lenguaje de consulta para bases de datos xml. Hay otra tendencia recientemente: Microsoft, IBM, etc. han desarrollado una gran cantidad de software intermedio como (InfoPath de Microsoft Office), que puede generar directamente páginas de entrada y otras funciones muy prácticas a partir del esquema XML. Y la aplicación generalizada de servicios web tendrá un impacto muy significativo en la arquitectura del software. En cuanto a las perspectivas de la arquitectura orientada a servicios (SOA) y cuándo la arquitectura de tres niveles pasará a la historia, todavía es difícil de determinar.

El desarrollo de aop también tendrá un profundo impacto en la arquitectura de software. Sin embargo, en la arquitectura orientada a objetos, ya sea aspectoJ o jboss-aop o aspectoWerks y nanning tienen sus propios problemas serios: la mantenibilidad es muy baja. Malo, por lo que será difícil llegar lejos. Quizás sea una buena idea que se utilice en servicios web.

Como lenguajes icónicos del modelo semántico del W3C, es difícil imaginar que rdf y owl tendrán un gran impacto en la arquitectura empresarial actual. Pero si hace lo que dice, cambia ampliamente la estructura de la información. También tendrá un profundo impacto en la arquitectura del software.

Algunos consejos sobre diseño arquitectónico:

Intente construir una capa de objetos persistentes completa. Puede obtener altos rendimientos.

Intente superponer y bloquear cada función. El módulo se basa en la apariencia supuesta de otros módulos.

No puede confiar en datos estáticos para implementar el modo IOC. Debe confiar en la interfaz de función de datos. Los datos estáticos son solo uno de los métodos de implementación de la función de datos. interfaz

Al diseñar la arquitectura, se admite xml en lugar de depender de él. Sin embargo, puede proporcionar la implementación de una única versión xml

Desde una perspectiva empresarial: la arquitectura del software debe ser. Sin embargo, una arquitectura empresarial que refleja profundamente las reglas internas del negocio debido a que el negocio cambia con frecuencia, es difícil que la arquitectura del software permanezca constante, pero los cambios frecuentes en el negocio no deberían ser la razón para cambios frecuentes y a gran escala en. Arquitectura de software. La arquitectura de software debe ser una arquitectura basada en cambios.

Una empresa tiene sus razones para existir estable durante un período de tiempo (no hablemos de eso por ahora). Hay muchos casos de uso dentro de la empresa. Cada caso de uso tiene reglas fijas y cada regla tiene. algunos disponibles Cada uno de los elementos determinados es medible desde una determinada dimensión. Nuestra arquitectura primero debe asegurarse de que se adapta perfectamente a cada elemento y a cada método de medición. Muchas arquitecturas fallidas se deben a los cambios en los métodos de medición de muchos elementos. .

Cada caso de uso tiene reglas. Cuando analizamos los casos de uso empresarial, a menudo asumimos que algunas reglas son a priori y estables. Sin embargo, los cambios comerciales posteriores a menudo demuestran que esta visión es incorrecta. ha pagado un precio irreparable por ello.

Una gran cantidad de hechos demuestran que los cambios en las reglas son a menudo la causa fundamental de los cambios en los casos de uso. Por lo tanto, nuestra arquitectura debe adaptarse a los cambios de reglas tanto como sea posible y establecer plantillas de reglas tanto como sea posible.

Cada caso de uso está relacionado con diferentes roles. La generación de cada caso de uso debe deberse al cambio del rol (nota: no reemplazo, sino mejora o debilitamiento), por lo que prestar atención a varias situaciones posibles del rol es de gran importancia para el diseño de la arquitectura. En nuestra arquitectura actual de tres niveles, los roles se corresponden perfectamente con el concepto de interfaz.

En un sistema, muchos casos de uso están relacionados entre sí. Teniendo en cuenta que cada caso de uso puede tener diferentes casos especiales, el principio de inversión de dependencia debe adoptarse tanto como sea posible en el diseño de la arquitectura. Si la arquitectura lo permite, se puede utilizar el modelo de mensajería (JMS). Esto reduce el acoplamiento.

Ahora hablemos del impacto que la estabilidad empresarial tiene como razón de ser en el negocio. La existencia es razonable, lo que ciertamente es cierto en este caso. Los negocios existen gracias a las personas, por lo que preguntar el motivo de la existencia del negocio significa preguntar a diferentes roles por qué necesitan este negocio y por qué les gusta o no el caso de uso comercial actual. Todos esos roles deben reservarse en el sistema. "Continuará"

Hay varios principios que se pueden considerar en el diseño arquitectónico:

Los casos de uso deben subdividirse tanto como sea posible

Los casos de uso deben ser lo más abstracto posible

Los roles deben ser lo más independientes posible

Principio de independencia de medición de ítems

Buscar la simplicidad

Ejemplos relevantes no se proporcionan aquí y se proporcionarán ejemplos en futuras actualizaciones.

La relación entre negocio y patrones

La relación entre algunos casos de uso en el negocio suele ser muy similar a algunos patrones convencionales. Pero a medida que pasó el tiempo, se fue alejando gradualmente del modelo anterior. Este es un fenómeno normal. Sin embargo, esto tiene requisitos muy altos en la arquitectura del sistema, lo que requiere que la arquitectura del sistema pueda adaptarse al reemplazo de algunos modelos. Aquí notamos los cambios de roles mutuos entre casos de uso lo antes posible para prepararnos para las actualizaciones de arquitectura.