Trabajando con el DomainDataSource….Canela fina, fina!

[Luis, va por tí…un poquito de cremita, canela fina, fina..]

En un post anterior os comentaba que una de las novedades de la última versión de RIA Services es que se ha simplificado enormemente el trabajo con el componente DomainDataSource.

Este componente nos va permitir trabajar de una manera bastante cómoda contra servicios de dominio que se exponen con RIA Services.

Hasta la salida de la versión beta, la utilización de este componente requería escribir bastante código XAML.En este post ya vimos cómo se usaba este control y algún ejemplo del código XAML a escribir.

En aplicaciones de negocio las operaciones de altas,bajas y modificaciones son las operaciones más habituales…listados, maestros-detalles, disponer de filtros, permitir ordenar…..es en todas estas situaciones dónde el control DomainDataSource nos debe ahorrar mucho trabajo.

Pero hasta la salida de la versión beta para hacer estas operaciones era necesario escribir demasiado código XAML. Demasiado código para tareas tan habituales.

Yo soy de la opinión que las tareas más habituales deben poder hacerse de la manera más automática y productiva posible…

Pues bien, con la Beta de RIA Services la cosa cambia y se simplifica enormemente el trabajo…a través de operaciones de arrastrar-soltar y con configuraciones a través de menús de propiedades pueden realizarse las tareas más habituales.

A nivel de servidor, los pasos que debemos realizar son los mismos que veíamos hasta ahora. Una vez que tenemos el DomainService creado y queremos usarlo en el cliente Silverlight es cuando la cosa cambia.

El primer paso es acceder al menú DataSource, desde el cuál podremos ver todos los DomainServices que expone el servidor y desde el cuál podremos hacer todas las operaciones que necesitamos.

ViewDataSource

El primer paso va a ser hacer un listado de los empleados. Para ello, sólo tenemos que seleccionar el DomainService en el menú DataSource, indicar que queremos que se muestre como un DataGrid y arrastrarlo a la interfaz Silverlight. De manera inmediata tenemos un grid que muestra la lista de empleados

DataSource  Grid

Fijaros en la imagen, que al seleccionar la servicio Empleados podemos elegir cómo queremos que se muestre cuando lo arrastramos a la página; DataGrid, Details o también podemos elegir otro control, por ejemplo, un listbox.

Del mismo modo en que podemos elegir como se va a dibujar la entidad completa, también podemos personalizar cómo se va a representar cualquier propiedad de la misma…por ejemplo, fijaros que en las fechas se muestra un calendar, pero podrías decidir que sólo queremos mostrar una etiqueta….todo desde el menú DataSource y sin tocar nada de código XAML. (si seleccionamos la opción “None”, esa propiedad no se mostrará)

Fijaros también en que está seleccionado el método “GetEmployeesQuery”. Este es el único método de tipo Query del servicio. Si tuviese varios, es aquí dónde podríamos elegir cuál de los métodos del servicio queremos que se utilice cuando lo arrastramos a la página.

Customize

Por ejemplo, si indicamos que queremos ver los detalles y lo arrastramos, tendremos el siguiente resultado:

Details

Meter paginación al listado anterior veréis que también es muy sencillo.

Lo primero que tendréis que hacer es incluir en la Toolbox el control DataPager. Desde la toolbox, botón derecho “Add Items”.

Una vez que tenemos el control DataPager lo arrastramos a la página, configuramos el control para que se vean 5 páginas en las propiedades y le indicamos que tiene que paginar la lista de empleados…¿Cómo?

Pues tan fácil como arrastrar la entidad Empleados del DomainService (la misma que hemos arrastrado para ver el grid) sobre el control DataPager. Con esta simple acción ya queda configurado!! Ya tenemos paginación sobre el listado.

AddControl DataPager

Y si queremos hacer un maestro-detalle? Pues seguimos arrastrando 🙂

Para el listado hemos visto antes que hemos arrastrado la entidad Empleados desde el nodo principal, indicamos que queríamos que se viese como un DataGrid.

Si desplegamos la entidad, veremos todas sus propiedades. Seleccionamos el nodo “Employees1” y lo arrastramos a la página, indicando que se vea como una formulario de detalles…..Ya ya está, ya tenemos un maestro detalle!

GenerateDetailsMasterDetail

Como veis el trabajo se simplifica bastante y de una manera muy sencilla podemos conseguir cosas bastante interesantes…

Pues sí que va a ser WCF…

En un post anterior comentaba cómo una de las novedades de la última versión de RIA Services es que se integra dentro de la familia WCF. Ahora toca comprobar cómo ha quedado.

Para poder comprobarlo, lo que he hecho es hacer un ejemplo sencillo del mismo modo que lo hacía con las versiones anteriores. En este post podéis ver los principales pasos a seguir.

Sin hacer ningún paso más de los que hacíamos en las versiones anteriores, ya tenemos la comunicación WCF funcionando. La comunicación es HTTP, usando protocolo binario.

Por lo tanto, al menos de momento, la integración de RIA Services en la familia WCF no ha supuesto una mayor complejidad en este tipo de aplicaciones.

Al crear la aplicación, el DomainService crea un servicio WCF implícito, que el cliente es capaz de instanciar y usar para realizar las peticiones. La estructura del servicio es:

http://[hostname]/[namespacename]-[classname].svc 

Si podemos en el navegador la URL de nuestro servicio, veremos que éste está disponible…

proxywsdl

En la relación entre la aplicación Silverlight y el DomainService no es necesario hacer nada más.

En el servidor se van creando los servicios que consideremos y en el cliente Silverlight los podemos ir usando sin ningún trabajo extra, ya que los proxys se crean de manera automática y transparente, tal y como se hacía en la versiones anteriores. (si os fijáis en los ficheros web.config no veréis “nada” parecido a lo que veis en los servicios WCF tradicionales)

Por lo tanto, al ser un servicio WCF también lo podemos instanciar desde cualquier otra aplicación como si de un servicio “normal” se tratara. Por ejemplo, desde una aplicación WinForm podéis hacer:

AddReference

Si os fijáis cómo queda el fichero de configuración de la aplicación WinForm, veréis que queda exactamente igual como quedaría si el servicio WCF fuese un servicio creado directamente.

Por ejemplo, en la sección cliente podéis ver los dos endpoints que se crean por defecto:

<client>
<endpoint address="http://localhost:30335/Services/BusinessApp-Web-EmpService.svc/soap"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_EmpServiceDomainService"
contract="ServiceReference1.EmpServiceDomainService" name="BasicHttpBinding_EmpServiceDomainService" />
<endpoint address="http://localhost:30335/ServicesBusinessApp-Web-EmpService.svc/binary"
binding="customBinding" bindingConfiguration="BinaryHttpBinding_EmpServiceDomainService"
contract="ServiceReference1.EmpServiceDomainService" name="BinaryHttpBinding_EmpServiceDomainService" />
</client>


Como veis, la integración de RIA Services en la familia WCF no ha supuesto una mayor complejidad en este tipo de aplicaciones….pero si será un beneficio, ya que nos permitirá beneficiarnos de algunas de las características de WCF.
 
En próximos post espero poder mostrar alguna característica interesante: Cómo hacer uso de los Service Behavior, Operation Behavior o cómo poder crear los servicios svc de forma explícita, por ejemplo, para exponer un servicio usando JSON o REST.

Por fin un poco de cordura!

Desde el PDC nos llega una interesante noticia y es que se van a unificar varias tecnologías de comunicación de las que dispone Microsoft en una.

RIA Services y ADO.NET Data Services pasan a integrarse dentro de la familia de WCF.

Desde los inicios de WCF uno de los aspectos destacables de esta tecnología siempre me ha parecido que era el hecho de que ofrezca un marco de trabajo unificado para crear aplicaciones distribuidas.

Ya no teníamos que pensar si usar servicios Web ASP.NET, Remoting, Enterprise Services o lo que fuera…teníamos WCF!! que aúna toda la funcionalidad de todas estas tecnologías bajo un modelo de programación único.

Pero últimamente me daba la sensación de que esta idea se estaba perdiendo y que volvíamos a lo mismo de antes…

ADO.NET Data Services y RIA Services eran dos claros ejemplos de esto, ya que ambas son tecnologías para crear aplicaciones distribuidas y que no usaban WCF. Se estaba perdiendo el carácter unificador, el hecho de tener un única tecnología con la que podamos hacer todo lo que queramos.

image

Cierto es que WCF en algunas ocasiones podría resultar un poco complicado de entender pero no es menos cierto que el hecho de unificar estas tecnologías no tiene por qué implicar que DataServices y RIA Services se compliquen.

El tiempo sólo nos dirá si ganamos o perdemos, pero al menos yo la considero una decisión acertada.

WCF RIA Services Beta

Ya tenemos desde ayer disponible la beta de WCF RIA Services, lo que antes conocíamos como .NET RIA Services.

La palabra WCF viene porque RIA Services formará parte de la familia WCF, como ADO.NET DataServices, que también pasa a llamarse WCF Data Services.

Novedades? Unas cuentas…por destacar algunas:

  • Integración con Visual Studio 2010 Beta 2.
  • El instalador de WCF Ria Services se incluye también dentro del instalador de Silverlight 4.
  • Integración con WCF, eso sí, sin perder la sencillez de manejo (ya veremos)
  • El canal de comunicación por defecto es binario.
  • Simplificar el trabajo con DomainDataSource (por ejemplo, evitando tener que acudir tanto el código XAML para relacionar los controles con el DomainDataSource)
  • Mejora en el tratamiento de errores, tanto del cliente como del servidor.
  • Corrección de muchos bugs.
  • Plantilla de Visual Studio más completa (Business Application Template), con más funcionalidad incluida, como el soporte a la globalización.
  • …..

Enlaces de interés:

Data Dude: Partial Projects

En un post anterior os hablaba de los Composite Projects, una característica de Visual Studio Database Edition que nos permite dividir base de datos grandes y complejas en múltiples proyectos de base de datos, dependientes unos de otros, y que pueden desplegarse todos a la vez.

En esta ocasión os hablaré de una característica relacionada, los proyectos parciales.

Los proyectos parciales permiten compartir una misma implementación entre múltiples proyectos, manteniendo una única definición de la misma.

La característica podría ser similar a los shares que permite el gestor de fuentes SourceSafe.

Imagina un equipo de desarrollo que tiene una línea base que define el schema de la base de datos. A partir de esta línea base se crean nuevas base de datos según surgen las necesidades.

Cuando se crea una nueva definición a partir de la línea base, cada equipo coge la definición base y la incorpora (copy-paste) a su proyecto….pero claro, aunque las nuevas definiciones parten de la misma base, no tienen ninguna relación entre ellas y por ejemplo, un cambio en la línea base no se ve reflejado en el resto.

Los proyectos parciales es esto lo que te permiten, poder añadir ficheros de tu proyecto de base de datos que son de otro. La línea base debería exponer una determinada  lista de ficheros que serán usando por el resto de proyectos.

Vamos a suponer un escenario muy sencillo, dónde tenemos dos proyectos de base de datos, uno con la definición de las tablas y otro con la definición de los procedimientos almacenados.

En el proyecto de las tablas, tendremos que exportar la definición de las mismas, para poder emplearlo dentro del proyecto de procedimientos.

Sobre Schemas>dbo>Tables, seleccionamos la opción de “exportar como proyecto parcial”.

image

Indicamos el nombre que queremos darle al fichero e indicamos que queremos que el fichero generado se añada dentro del proyecto de base de datos.

image

image

Una vez que tenemos el fichero generamos, sólo tenemos que incluirlo dentro del proyecto de procedimientos.

image

Como veréis, una vez importado, la nueva tabla os aparece (Schema View) como una tabla más del proyecto.

image

Data Dude: Composite Projects

Ya hace unas semanas que coincidí con Juan Irigoyen en una charla en Santander, dónde nos habló de VStudio Database Edition 2010

Una de las características que quedaron fuera y que me parece interesante comentar son los Composite Projects.

La idea es muy sencilla; poder dividir base de datos grandes y complejas en múltiples proyectos de base de datos, dependientes unos de otros, y que pueden desplegarse todos a la vez.

Simplificando, se podría decir que son como las referencias de los proyectos tradicionales de VStudio, pero llevado al mundo de las base de datos.

image

Por ejemplo, podrías tener un proyecto de base de datos que contenga la definición de tus tablas y vistas y en otro proyecto tener los procedimientos y funciones que atacan tu base de datos.

Esta situación, que en proyectos grandes podría ayudar a tener más organizada la base de datos, también podrías servirnos, por ejemplo, para establecer diferentes niveles de seguridad….por ejemplo, nos puede interesar que cierto grupo de desarrolladores cree los procedimientos almacenados pero que no puedan hacer cambios en el schema de la base de datos. Si lo separamos en proyectos, podemos dar diferentes permisos de acceso.

Como veis en la imagen se puede enlazar con otro proyecto de base de datos que esté dentro de la misma solución o contra un fichero .dbschema generado por un proyecto de base de datos que se encuentra en otra ubicación.

image

Cuando se despliega el proyecto principal sobre la base de datos, antes de desplegarlo se despliegan sus dependencias. Si están configurados para que se desplieguen en la misma base de datos, el resultado final serán una base de datos que contenga el contenido de todos los proyectos de base de datos.