Capas de reutilización del modelo de datos

Diseñar un modelo de datos para la reutilización es una de las áreas más importantes en un proyecto de software. Un modelo de datos bien diseñado tiene un efecto sinérgico, el conjunto es más importante que la suma de sus partes. Por el contrario, un modelo de datos mal diseñado perjudica la calidad y la capacidad de mantenimiento de una aplicación.

Existe una tentación de definir el ciclo de vida de un tipo de caso inmediatamente después de crearlo. Puede desarrollar ciclos de vida del caso rápidamente en App Studio con vistas que contienen numerosas propiedades, todo a nivel de caso. Este enfoque se torna contraproducente debido a la falta de clases de datos reutilizables y propiedades a nivel de grupo de trabajo que se comparten con otros casos. Toma horas volver a factorizar y probar el código.

Es mejor comenzar por agrupar propiedades relacionadas mediante clases de datos que contienen las vistas para mostrar esas propiedades. Crear clases de datos promueve la reutilización entre los tipos de caso de una aplicación. Las clases de datos mejoran y simplifican el mantenimiento de la aplicación.

Una de las finalidades principales de un caso es administrar un conjunto de datos específico. Administrar los datos implica un rol diferente que ser los datos. La finalidad principal de los datos es que se los use para uno o más casos.

Los casos tienen dos tipos de propiedades:

No es usual necesitar definir propiedades nuevas para Estado de transacción e historial.

En ciertos escenarios, deberá definir un tipo de caso con un ciclo de vida o comportamiento pequeño o nulo a fin de usar el tipo de caso principalmente para almacenar datos de forma local. El ciclo de vida del caso puede consistir en cambiar pyStatusWork de New (Nuevo) a Open (Abierto) a Resolved-Completed (Resuelto-completado). Podría tener una asignación única con un Acuerdo de nivel de servicio (SLA).

Un caso puede parecer simple al principio, por lo que puede considerar que no es necesario agregar un tipo de campo Data Relationship (Relación de datos). Sin embargo, la práctica recomendada para los cambios es siempre asociar al menos un tipo de campo Data Relationship (Relación de datos) con un tipo de caso. Haga que uno de los tipos de campo Data Relationship (Relación de datos) sea sinónimo del tipo de caso. Esto lo ayudará a evitar propiedades escalares en el tipo de caso.  

Por ejemplo, una instancia Data-Warranty que contiene información estática (como los términos y condiciones de la garantía de un producto) es de solo lectura. Por otro lado, una instancia Data-Warranty-Claim contiene propiedades que varían dinámicamente como PurchaseDate, ClaimDate, ExpirationDate y Expired. En la vista que muestra esas propiedades adicionales, las primeras dos son modificables. Por el contrario, el segundo conjunto de propiedades se pueden calcular y son de solo lectura.

La aplicación de muestra Event Booking también sigue este patrón. Los campos dentro de una instancia FSG-Data-Hotel son estáticos desde la perspectiva de un caso de evento. Por el contrario, los campos dentro de una instancia RoomsRequest son dinámicos.

El modelo de datos de un caso también debe considerar la facilidad con la que se propagan los datos del cliente de un caso a otro. Un grupo de campos se puede completar inmediatamente antes de la creación de un subcaso o un caso de spin-off. Un grupo de campos que se usa de esta manera como mínimo debe definirse en el nivel de clase de grupo de trabajo. Si el subcaso o caso de spin-off es una extensión del componente de un tipo de caso, la clase que corresponde para el grupo de campos debe ser más genérica, por ejemplo, Work-Cover-.