Relaciones Anidadas

6.1 RELACIONES ANIDADAS

El modelo relacional anidado es una extensión del modelo relacional en la que los dominios pueden ser atómicos o de relación. Por tanto, el valor de las tuplas de los atributos puede ser una relación, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una única tupla de las relaciones anidadas. Si se consideran las tuplas de las relaciones anidadas como elementos de datos, se tiene una correspondencia uno a uno entre los elementos de datos y los objetos de la vista de la base de datos del usuario.

6.2 TIPOS COMPLEJOS

La compatibilidad de tipos complejos en WCF RIA Services proporciona un medio para encapsular un conjunto de propiedades de entidad en una sola propiedad (compleja). Estos tipos se pueden utilizar para simplificar una entidad cuando contiene un subconjunto concreto de propiedades relacionadas. Los tipos complejos pueden ser reutilizados por otra entidad (diferente) que comparte el mismo subconjunto de propiedades. Un ejemplo común de un tipo complejo es un elemento Address, que reúne las propiedades de entidad necesarias para especificar una dirección. El conjunto de propiedades de un tipo Address puede incluir, por ejemplo, las propiedades de entidad StreetAddress,City, StateProvince, PostalCode y Country. Este tipo complejo pueden utilizarlo las entidades Customer y Contactproporcionadas que comparten este conjunto de propiedades. Eso hace que, una vez definido, el tipo Addresspersonalizado se pueda utilizar como una propiedad de entidad en otras entidades.

Un tipo complejo es una plantilla para definir propiedades estructuradas avanzadas en tipos de entidad o en otras entidades complejas, ya que un tipo complejo puede contener propiedades que son también de un tipo complejo. Un tipo complejo debe especificar un nombre que es único en su espacio de nombres y, opcionalmente, contiene datos en forma de una o más propiedades. Los tipos complejos solo pueden existir como propiedades en tipos de entidad u otros tipos complejos, ya que no tienen identidades y, por lo tanto, no pueden existir independientemente. Son tipos genuinos y, por consiguiente, se pueden crear instancias de ellos y utilizarse en código, pero no se pueden consultar directamente ni conservar en una base de datos, como sí se puede con los tipos de entidad. Los tipos complejos también se diferencian de las entidades en que no pueden participar en una asociación. De ahí que no se puedan definir propiedades de navegación en tipos complejos mientras que sí se puede realizar esta acción en tipos de entidad.

Se ha agregado compatibilidad con tipos complejos que no son de entidad en WCF RIA Services V1.0 SP1. Concretamente, se proporciona compatibilidad con la generación de código de tipos complejos que derivan de la clase base ComplexObject. La compatibilidad con la generación de proxies de clientes es igual de avanzada que la compatibilidad con entidades de RIA Services . También se proporciona compatibilidad de metadatos en el mismo nivel que entidades, como validación profunda, seguimiento de cambios, sesiones de edición y parámetros de tipo complejo. Esto significa que los tipos personalizados, como Address, se pueden utilizar ahora no solo como propiedades de entidad sino también como parámetros o como valores devueltos para métodos de servicio de dominio.

La representación XML del tipo complejo

RIA Services usa el lenguaje de definición de esquemas conceptuales (CSDL) para especificar modelos de datos. Es un lenguaje basado en XML que describe las entidades, las relaciones y las funciones que conforman un modelo conceptual de una aplicación controlada por datos. La especificación del nuevo tipo MailAddress está en la sección CSDL del código XML.

Para tener acceso a él, seleccione AdventureWorksModel.edmx en el Explorador de soluciones, haga clic con el botón secundario y seleccione Abrir con y, a continuación, elija Editor XML (texto). Visual Studio 2010 tendrá que cerrar la Vista de diseño del modelo de datos para abrir la representación XML; por lo tanto, seleccione Sí para aprobar esta acción. Observe que la nueva propiedad MailAddress está especificada en el elemento <EntityType Name=”Address”>:

<Property Name="MailAddress" Type="AdventureWorksLTModel.MailAddress" Nullable="false" />

La propiedad MailAddress está definida en su propio elemento debajo de las secciones donde están definidas las asociaciones.

<ComplexType Name="MailAddress">

<Property Type="String" Name="AddressLine1" Nullable="false" MaxLength="60" FixedLength="false" Unicode="true" />

<Property Type="String" Name="AddressLine2" MaxLength="60" FixedLength="false" Unicode="true" />

<Property Type="String" Name="City" Nullable="false" MaxLength="30" FixedLength="false" Unicode="true" />

<Property Type="String" Name="StateProvince" Nullable="false" MaxLength="50" FixedLength="false" Unicode="true" />

<Property Type="String" Name="CountryRegion" Nullable="false" MaxLength="50" FixedLength="false" Unicode="true" />

<Property Type="String" Name="PostalCode" Nullable="false" MaxLength="15" FixedLength="false" Unicode="true" />

</ComplexType>

Observe que no hay ningún elemento <Key> dentro de un elemento <ComplexType> como sí lo hay en un elemento .

Reutilizar un tipo complejo en otra entidad

Si se tuviera un tipo de entidad Manufacturer que contuviera el mismo conjunto de propiedades de dirección, se podrían encapsular estas en el tipo complejo . Use Refactorizar en nuevo tipo complejo como ya hizo para crear el tipo complejo y, a continuación, cambie el tipo y el nombre en la ventana Propiedades. Los campos señalarán sus entidades respectivas. Por ejemplo, el campo City para el elemento MailAddress de la entidad Address se asignará aAddress.City, mientras que este campo se asignará a Manufacturer.City para el tipo de entidad Manufacturer. Use la tabla Detalles de la asignación para asegurarse de que las propiedades se asignen de nuevo a las columnas correctas de la base de datos.

6.3 HERENCIA

La herencia

...