Generación de código de cliente
Cuando se vincula un proyecto de Silverlight y un proyecto de nivel intermedio utilizando WCF RIA Services, RIA Services genera clases de proxy de cliente para la aplicación cliente basándose en las entidades y operaciones que se han expuesto en el nivel intermedio. Dado que RIA Services genera estas clases, no es necesario duplicar la lógica de aplicación del nivel intermedio en el nivel de presentación. Los cambios que se realicen en el código de nivel intermedio se sincronizan con el código de nivel de presentación cuando se recompila el proyecto de cliente. Cuando se agrega un vínculo a RIA Services a una solución, se agrega una dependencia de compilación explícita a la solución que fuerza la compilación del proyecto de servidor antes de la generación de código para el proyecto de cliente.
El código generado reside en una carpeta denominada Generated_Code en el proyecto de cliente. Par ver esta carpeta, debe seleccionar Mostrar todos los archivos en la ventana del Explorador de soluciones para el proyecto de cliente. No debe modificar directamente las clases en la carpeta Generated_Code porque se sobrescribirán cuando se recompile el proyecto de cliente. Sin embargo, puede abrir el archivo generado para ver el código que está disponible para el proyecto de cliente.
.png "RIA_GeneratedCode")
El algoritmo que genera el código de cliente sigue estas reglas básicas:
Analice todos los ensamblados a los que el proyecto de nivel intermedio para las clases de servicio de dominio, clases de entidad o código compartido hace referencia o compila.
Para cada servicio de dominio que se anota con el atributo EnableClientAccessAttribute, genere una clase que derive de la clase DomainContext.
Para cada método de consulta, método de actualización con nombres (un método de actualización con la propiedad UsingCustomMethod establecida en true) u operación de invocación en la clase de servicio de dominio, genere un método en la clase de contexto de dominio.
Para cada clase de entidad expuesta por un servicio de dominio, genere una clase de proxy de entidad. Una clase de entidad se expone cuando es devuelta por un método de consulta.
Copie el código marcado para uso compartido con el proyecto de cliente.
La siguiente imagen muestra el código de cliente que se genera para un proyecto de nivel intermedio.
.png "Generación de código de cliente")
DomainService y DomainContext
Se genera una clase que deriva de DomainContext para cada clase de servicio de dominio de acuerdo con las reglas siguientes:
La clase de contexto de dominio se genera con el mismo espacio de nombres que el servicio de dominio.
La clase de contexto de dominio contiene tres constructores:
Un constructor predeterminado que incrusta el URI necesario para comunicarse con el servicio de dominio mediante HTTP utilizando una clase WebDomainClient.
Un constructor que permite que el cliente especifique un URI alternativo.
Un constructor que permite que el cliente proporcione una implementación de DomainClient personalizada (normalmente se utiliza para la realización de pruebas unitarias o la redirección a una capa de transporte personalizada).
Para cada método de consulta en la clase de servicio de dominio, genere un método EntityQuery que se pueda utilizar en el proyecto de cliente para cargar entidades.
Para cada operación de invocación, genere un método InvokeOperation correspondiente que se pueda utilizar para invocar esa operación de forma asincrónica.
Para cada método marcado con el atributo Update(UsingCustomMethod=true), genere los métodos para invocarlo y determinar si se ha invocado.
Los métodos públicos en el servicio de dominio que realizan inserciones, actualizaciones o eliminaciones provocan que el elemento EntityContainer generado en el contexto de dominio se construya con una marca EntitySetOperations que indica qué operaciones se permiten en el cliente.
Clase de entidad y clase de proxy de entidad
Las reglas siguientes se aplican cuando se genera la clase de proxy de entidad:
La clase de proxy se genera con los mismos nombre y espacio de nombres que la clase de entidad en el nivel intermedio.
El tipo de entidad raíz deriva de la clase Entity. Los tipos de entidad derivados derivan de los tipos base correspondientes expuestos por el nivel intermedio.
Cada propiedad pública que contiene un tipo admitido y no se marca con el atributo ExcludeAttribute en la clase de entidad se genera en la clase de proxy, a menos que la propiedad ya exista en el proyecto de cliente. Para obtener más información, vea la sección "Evitar miembros duplicados" más adelante en este tema. Object no es un tipo admitido.
Cada establecedor de propiedad contendrá código que realiza la validación y notifica a los clientes que la propiedad está cambiando y ha cambiado.
Los atributos de metadatos se combinan con la clase de entidad en el código generado. No existirá ninguna clase de metadatos en el cliente.
Si es posible, los atributos personalizados se propagan a la clase de proxy. Para obtener una descripción de las condiciones que deben existir para que el atributo personalizado exista en el proyecto de cliente, vea la sección "Atributos personalizados" que figura más abajo.
Un atributo CustomValidationAttribute solamente se propaga al miembro si el mismo método de tipo y de validación se especifica en más de una instancia del atributo CustomValidationAttribute para ese miembro.
Atributos personalizados
Los atributos personalizados se propagan a la clase de proxy si la inclusión del atributo personalizado no produce un error de compilación en el proyecto de cliente. Para la propagación del atributo personalizado, deben existir las condiciones siguientes:
El tipo de atributo personalizado debe estar disponible en el proyecto de cliente.
Los tipos especificados en la declaración de atributos personalizados deben estar disponibles en el proyecto de cliente.
El tipo de atributo personalizado debe exponer establecedores públicos para todas sus propiedades, o exponer un constructor que permita el establecimiento de propiedades que no tengan establecedores públicos.
Si un atributo personalizado necesario no se propaga al cliente, puede que sea necesario agregar una referencia de ensamblado en el proyecto de cliente. Agregue una referencia a los ensamblados que se necesiten para la compilación del atributo personalizado en el proyecto de cliente. También puede compartir un atributo personalizado entre los niveles definiéndolo en un archivo compartido.
Código compartido
Cuando se comparten archivos de código entre el nivel intermedio y el nivel de presentación, el código se copia sin ningún cambio en el proyecto de cliente. Debe especificar un archivo para uso compartido asignándole un nombre con el patrón *.shared.cs o *.shared.vb. La estructura de directorios del proyecto de nivel intermedio que contiene los archivos compartidos se replican en la carpeta Generated_Code.
Cuando se agrega un tipo personalizado en un archivo de código compartido y, a continuación, se devuelve ese tipo desde una operación de invocación, el método generado en el contexto de dominio no devolverá el tipo personalizado. En su lugar, el método en el contexto de dominio devolverá un tipo que forme parte del marco. Por ejemplo, cuando se crea un tipo personalizado denominado MyCustomDictionary que implementa IDictionary y se especifica el citado tipo como el valor devuelto para una operación de dominio, el método generado en el contexto de dominio no devolverá MyCustomDictionary. En su lugar, devolverá un objeto Dictionary.
Para obtener más información, vea Código compartido.
Evitar miembros duplicados
Cuando se genera una clase de proxy de entidad, es posible que el mismo tipo y el mismo miembro ya se hayan definido en el proyecto de cliente utilizando tipos parciales. Puede haber definido el miembro en código compartido o en código que solo existe en el proyecto de cliente. RIA Services comprueba los miembros existentes antes de generar la clase de proxy. Los miembros que ya estén definidos no se generarán en la clase de proxy.