Ya tenemos nueva versión de RIA Services

Bueno, después de la salida de Silverlight 3, ya tenemos nueva preview de RIA Services.

Incluye alguna mejora sobre características que ya estaban, corrección de errores y alguna nueva funcionalidad, por ejemplo los primeros pasos para la integracíón con ADO.NET Data Services. Haciendo copy-paste de los cambios….

API improvements:

  • Improved DomainContext API – much more easier to issue multiple queries simultaneously, track completion, cancel requests etc. using callbacks. Also you can now see consistency with what you authored on the server DomainService.
  • Consistent pattern for authoring CRUD operations in the DomainService on the server.

 

Some new capabilities:

  • Extensibility around authentication model on the client – for example, to plug in OpenID. There are other extensibility hooks for framework authors and app authors also included in various parts of the stack on the server and on the client.
  • Ability to create n-tier class libraries. You can now have a server Class Library to put your DomainService in, link it to a Silverlight Class Library, and then reference the pair across multiple apps.
  • Initial bits of integration with ADO.NET Data Services. For example, you can now expose an explicit service by layering a DataService on top of DomainService.

 

Some big time cleanup:

  • Fixed the shared code model. Just put something in a .shared.cs (or .shared.vb) file, and we understand it. No need for adding the confusing [Shared] metadata attribute… in fact the attribute is simply gone!
  • Updated our code-gen to support additional partial class scenarios much more straight-forwardly such as computed properties, custom initialization logic etc.

 

Tip: Evitando la herencia en el fichero de configuración para subcarpetas de ASP.NET

En un mismo Site tengo dos aplicaciones web. Una colgando directamente del raíz de Site y otra en un directorio virtual que cuelga de éste.

Cada aplicación tiene su fichero de configuración (web.config). La segunda aplicación, la del directorio virtual, hereda todos los valores de configuración del fichero de configuración raíz.

El fichero de configuración real que tendrá la segunda aplicación es el contenido del fichero de configuración que tiene el nodo raíz más su propio fichero de configuración físico.

En algunas circunstancias esta situación nos puede venir bien pero en otras no tan bien y nos puede dar problemas.

Por ejemplo, si tenemos definida la misma cadena de conexión en ambos ficheros pero con valores diferentes (si los valores son iguales no hay problema ) veremos que la aplicación nos da un error:

<add name="Database" connectionString="Server=.;Initial Catalog=Database; Integrated Security = true" />

Configuration Error

Ya se ha agregado la entrada ‘Database.

(C:Inetpubwwwrootgeeksweb.config line 27)

Una solución para evitar esta situación es utilizar la cláusula remove, que nos va a permitir eliminar un valor heredado.

<connectionStrings>
  <remove name="Database"/>
  <add name="Database" connectionString="Server=.;Initial Catalog=Database; Integrated Security = true" />
</connectionStrings>

Si queremos borrar todas las opciones heredadas tenemos la cláusula clear.

<connectionStrings>
  <clear/>
  <add name="Database" connectionString="Server=.;Initial Catalog=Database; Integrated Security = true" />
</connectionStrings>

Y para terminar un apunte final. Si encriptais las cadenas de conexión, cosa que sería recomendable, la única opción que vais a poder utilizar es la de borrar todos los valores heredados con la sentencia clear.

Si usas la sentencia remove, al encriptar la cadena de conexión se pierde…si encriptas teniendo la clausula remove y desencriptas posteriormente verás como el remove ya no existe!!!!

Las clases de metadatos

En este post vamos a seguir profundizando en las características de RIA Services. En este caso vamos a hablar sobre las clases para los metadatos y las cosas que podemos hacer con ellas.

En los post anteriores hemos ido viendo un ejemplo de cómo crear una aplicación RIA haciendo uso de RIA Services.

En uno de los pasos, al crear el DomainService para exponer los servicios al cliente, nos salía una ventana como esta que pongo a continuación, desde la cual configurábamos la parte del modelo de datos que queremos exponer. Recordad que para crear el modelo hacíamos uso de Entity Framework.

9.1

En la parte inferior hay una opción que indica si deben generarse las clases de metadatos. En los post anteriores no habías comentado lo que hace esta opción y para qué sirve; ahora llega el momento de hacerlo.

Las clases de metadatos son clases parciales que nos va a permitir añadir más información a otros clases parciales.

En el ejemplo que estamos viendo estamos usando un modelo de datos de Entity Framework. Si viésemos el código generado al crear el modelo (podemos verlo en Northwind.Designer.cs) con nuestra entidad Suppliers, veríamos que existe una clase partial llamada Suppliers, con la definición de esta entidad.

public partial class Suppliers : global::System.Data.Objects.DataClasses.EntityObject
 
Las clases de metadatos nos va a permitir añadir más información a estas clases autogeneradas, por ejemplo, añadir un campo más que no está en el modelo o simplemente completar la información que ya existe y que no está representada en el modelo; si un campo en obligatorio, si soporta cierto rango de valores etc….Lo que hacemos es completar el modelo.
 
Esta información extra se podría hacer modificando directamente las clases del modelo, pero al ser código autogenerado habría muchas opciones de perderlo en alguna modificación, por lo que es más recomendable hacerlo en una clase diferente.
 
Seleccionando el check de “generar clases de metadatos” lo que se hace es generar automáticamente la estructura de la clases de metadatos para todas las entidades del modelo. En nuestro ejemplo, nos genera el fichero SuppliersService.metada.cs, para poder añadir información extra a la entidad Suppliers.
 
Si no hubiéramos seleccionado esta opción siempre podríamos crear estas clases posteriormente, pero si tenemos muchas entidades puede ser un poco pesado hacerlo, así que si nos lo genera mejor.
 

image

Si veis la definición de la clase de metadatos verías algo así:

[MetadataTypeAttribute(typeof(Suppliers.SuppliersMetadata))]
public partial class Suppliers

A través de los atributos podemos añadir información, por ejemplo, añadir restricciones a las propiedades de la clase; si es obligatorio, que debe cumplir una expresión regular, un determinado tamaño etc..…incluso podríamos añadir nuestro propio validador personalizado.

[Required] [RegularExpression(“[A-Z][A-Za-z0-9]*”)] [StringLength(32)] public string Name;

Y por qué es útil esto para RIA Services?

Pues porque RIA Servives es capaz de usar esta información que le suministramos y respectará y usará estas restricciones durante la validación y la generación del código cliente.

Por ejemplo, si hiciésemos una aplicación con Silverligth usando DataGrid o el FormData esta información nos será de gran utilidad.

image

image