PERSISTENCIA
El Sistema de Persistencia Implícita nitro
La persistencia se suele conceder a las aplicaciones mediante el uso de acceso explícito a los sistemas de gestión de bases de datos (DBMS), tales como bases de datos orientadas a objetos o productos de mapeo objeto-relacional.
Inconvenientes:
- La legibilidad y mantenimiento.
- Portabilidad: dependencia directa del mecanismo de persistencia explícitamente en la implementación de la aplicación.
- Adaptabilidad pobre: La adaptación de los aspectos relacionados con la persistencia, tales como la adición de una nueva técnica de indexación, se hace comúnmente mediante el cambio y el volver a compilar el código fuente.
- los fragmentos similares de código que alcanzaron la misma funcionalidad que difiere de la estructura de datos, implica código redundante no va a refactorizarse y reutilizarse. Con la separación de las preocupaciones de persistencia y el uso de la reflexión, esta rutinas podrían ser genéricas y, por lo tanto, reutilizables.
- Complejidad. el programador está desarrollando la funcionalidad de la aplicación, lo que tiene que hacer llamadas explícitas a las API introducidas y / o en las extensiones añadidas al lenguaje de programación, no siendo posible razonar acerca de la lógica de aplicación en forma aislada.
Una plataforma de reflexión llamado Nitro que, independientemente del lenguaje de programación elegido por el programador, ofrece una gran capacidad de adaptación en tiempo de ejecución.
Desarrollo de software orientado a aspectos
En muchos casos, las preocupaciones significativas en las aplicaciones de software no se expresan fácilmente de forma modular.
Ejemplos de tales preocupaciones son las transacciones, la seguridad, la tala o la persistencia.
(AOSD) es una disciplina prometedora que sigue el principio de SoC en cualquier etapa del ciclo de vida del software. AOSD es una evolución de la programación orientada a aspectos (AOP).
Antecedentes a la persistencia como un aspecto
En la literatura AOSD, la persistencia es a menudo descrito como un candidato clásico para aspectization. En teoría, debe ser posible a:
- Modularize persistencia como un aspecto eficaz el empleo de técnicas de AOP.
- Reutilizar aspectos de persistencia, independientemente del tipo de aplicación.
- Desarrollar programas que desconocen la naturaleza persistente de sus datos.
Analizando los distintos aspectos de las implementaciones de persistencia, nos damos cuenta de que los objetivos anteriores no se consiguen fácilmente en ejemplos del mundo real.
La adaptación dinámica de Persistencia
Además de ser capaz de hacer dinámicamente objetos persistentes y devolverles a su estado no persistente, es interesante para adaptar sus características persistentes de una manera mediante programación.
El sistema reflectante nitro
La principal técnica que hemos utilizado para lograr los objetivos del sistema es la reflexión. La reflexión es la capacidad de un sistema de cálculo para razonar acerca y actuar sobre sí mismo, ajustándose a las condiciones cambiantes. Su dominio computacional se ve reforzada por su propia representación, ofreciendo su semántica y la estructura como datos computables.
La definición teórica de reflexión, considera que un cálculo reflexivo es un cálculo sobre el cálculo, es decir, un cálculo que tenga acceso al intérprete (lo que se llama la cosificación ). Hemos diseñado nitro siguiendo este concepto: si una aplicación sería capaz de acceder a su intérprete en tiempo de ejecución, se podría modificar su estructura y personalizar su semántica del lenguaje.
Lenguaje de especificación
Los lenguajes de programación se detallan en Nitro con los archivos de especificación del lenguaje.
La siguiente especificación es un primer ejemplo de un VerySimple definición del lenguaje sin ninguna verificación de la corrección semántica:
Bueno podéis averiguar mas sobre el tema de programacion sobre aspectos, persistencia, reflexión y nitro en las siguientes direcciones:
