Carga del modelo DataGraph de virtual member manager

Virtual member manager da soporte a dos formas de cargar el modelo DataGraph en la memoria: la carga dinámica y la carga estática. Cada método tienen sus ventajas.

Carga dinámica

La carga dinámica significa que el modelo DataGraph se carga en la memoria como un modelo ECore en la ejecución desde los archivos XSD a través de XSDEcoreBuilder.

Las ventajas que presenta este método son las siguientes:
Se extiende fácilmente
A diferencia de la carga estática, la carga dinámica no necesita generar código de modelo estático. Todas las definiciones de esquemas se definen y se cargan desde el archivo XSD.
Permite realizar cambios en el esquema incorporado de virtual member manager
Se pueden añadir nuevos tipos de propiedad a los tipos de entidad incorporados de virtual member manager por medio del archivo wimxmlextension.xml.
Ofrece soporte a la adición de un nuevo esquema en la ejecución
Los usuarios pueden llamar a la API createSchema API durante la ejecución para crear tipos de entidad y tipos de propiedad nuevos.
Las desventajas que presenta este método son las siguientes:
La carga es más lenta
El tiempo que se tarda en cargar el archivo XSD es mayor que el de carga del código del modelo estático. El proceso de carga se produce cada vez que se inicia virtual member manager.
No se pueden utilizar tipos nativos
En este planteamiento, los clientes no pueden difundir los DataObjects a los tipos nativos (como Person, Group) y utilizan los métodos nativos de estos tipos. Por ejemplo, los clientes sólo pueden utilizar el método setString(“givenname”, “Smith”) de DataObject para establecer el nombre especificado, pero no pueden utilizar setGivenname(“Smith”) de PersonAccount.
El rendimiento en la ejecución es más lento
El rendimiento de SDO con la carga dinámica es más lento que en el modelo estático.

Carga estática

La carga estática significa que se genera código de modelo estático mediante la generación de código EMF (Eclipse Modeling Framework) en tiempo de desarrollo. El código de modelo es una implementación EMF de SDO. La aplicación SDO utiliza el paquete del código del modelo generado. Este planteamiento ahorra el tiempo invertido en cargar el modelo de los archivos XSD en la carga dinámica. Permite que los usuarios difundan los DataObjects a tipos de objetos nativos para mejorar el rendimiento en ejecución.

Las ventajas que presenta este método son las siguientes:
La carga es más rápida
En comparación con la carga del modelo desde los archivos XSD, la modalidad de carga del código de modelo estático es más rápida. Esto hace que el tiempo de inicio de virtual member manager sea más corto.
Permite que los usuarios utilicen tipos nativos
DataObject se puede difundir a tipos nativos (como Person, Group) y utilizar los métodos nativos en estos tipos. Por ejemplo, DataObject se puede difundir a PersonAccount y se puede utilizar el método “setGivenname” para establecer la propiedad “givenname”.
Tiene mejor rendimiento de ejecución
Al utilizar tipos y métodos nativos, el rendimiento de ejecución de SDO es mejor que el método de carga dinámica.
Las desventajas que presenta este método son las siguientes:
Se extiende con menos facilidad
Para extender el esquema debe generar código de modelo estático a través del entorno de desarrollo Eclipse o RAD. Los usuarios de virtual member manager necesitan tener conocimientos de EMF, SDO y Esquema XML para realizar la extensión.
El cambio al esquema incorporado de virtual member manager es más difícil
Si desea añadir nuevos tipos de propiedad a los tipos de entidad incorporados de virtual member manager (como Person y Group), tendrá que modificar directamente wimdomain.xsd y volver a generar el código de modelo estático de virtual member manager.
No da soporte a la adición de un nuevo esquema en la ejecución
Como el código del modelo generado es fijo, no se puede ampliar el esquema de virtual member manager en la ejecución.


Condiciones de uso | Comentarios