Pues nada, después de 2 años trabajando en AvanGroup, ha llegado el momento de volver a cambiar de aires.
Guardaré un buen recuerdo de estos dos últimos años, los cuáles he tenido el placer de compartir con unos muy buenos compañeros.
Aún así, ha llegado el momento de buscar nuevos retos profesionales, y considero que en Plain Concepts los podré encontrar.
A finales de este mes, si no cambian de opinión, me incorporaré a Plain Concepts, dónde tendré la oportunidad de participar en proyectos bastante interesantes, con compañeros de gran nivel, cosa que apetece bastante.
Y claro está, intentaré seguir dando un poco de guerra a través del blog :-)
** cross-posting desde http://geeks.ms/blogs/ilanda
Ya llevamos una temporada hablando sobre el funcionamiento de WCF RIA Services y de cómo se puede emplear junto con Silverlight para realizar aplicaciones de negocio.
Hemos hablado de varias características interesantes pero no hemos hablado en ningún momento de cómo personalizar el diseño de la aplicación, de la interfaz Silverlight que hagamos…
Pues en esta ocasión toca hablar de diseño pero como no puede decir que el diseño sea mi fuerte, he optado por mostrar algunos recursos de los que disponemos para iniciarnos en este maravilloso mundo.
Dentro de la página de la Galería de Expression podéis encontrar un montón de ejemplos que os resultarán de gran utilidad, ya sea para aplicarlos directamente a vuestra aplicaciones, aprender de ellos o para partiendo de ellos hacer vuestras propias modificaciones utilizando Blend….bueno, para lo que queráis.
Por ejemplo, podéis encontrar un montón de temas que podéis aplicar directamente a las plantillas de proyecto de Silverlight.
Y pasar del estilo de la plantilla por defecto a una un poco más trabajada….sustituyendo simplemente el fichero de estilos por defecto por el que os descarguéis de la web de Expression.
** cross-posting desde http://geeks.ms/blogs/ilanda
Pues como lo prometido es deuda, en esta ocasión toca hablar sobre localización de aplicaciones Silverlight y más concretamente de cómo en el código XAML se puede indicar que use una cadena que se encuentra en un fichero de recursos.
Para este ejemplo he creado un proyecto de tipo “Silverlight Application” usando Visual Studio 2008 SP1 y Silverlight 3.
Una vez hecho, esto, he añadido al proyecto que contiene los ficheros xaml dos ficheros de recursos, dos ficheros resx; uno para la cultura por defecto y otro para la cultura ingles americano (en-US).
Les he llamado FicheroRecursos.resx y FicheroRecursos.en-US.resx
Una vez hecho esto, en cada uno de los ficheros he añadido una nueva entrada llamada “Cadena”. En el archivo por defecto he puesto el valor por defecto y en el otro el valor en ingles.
El siguiente paso es indicar en la aplicación Silverlight las culturas que ésta va a soportar; en nuestro caso bastaría con indicar la cultura “en-US”, porque en el resto de los casos sacaría los valores del fichero de recursos por defecto.
Para hacer esto, lo primero que tenemos que hacer es descargar el proyecto que contiene los ficheros xaml de la solución (Unload Project) y editar el fichero .csproj…con el editor de VStudio, con el notepad o con lo que queramos.
En el tag supportedCultures tenemos que añadir todas las culturas que queremos que soporte. Si hay varias, debemos separarlas por punto y coma.
<SupportedCultures>es-ES;en-US</SupportedCultures>
Una vez hecho esto, tenemos que volver a cargar el proyecto(Reload Project).
El siguiente paso es hacer los cambios necesarios para que desde el código XAML podamos tener acceso a las cadenas que hay dentro del fichero de recursos.
Cuando hemos creamos el fichero de recursos habréis visto que se ha creado un fichero llamado FicheroRecursos.Designer.cs que contiene una clase llamada “FicheroRecursos” que posibilita el acceso a las cadenas definidas dentro del fichero.
El “problema” es que por defecto tanto la clase como el constructor están declarados como internal y por tanto, no podremos acceder desde el código XAML directamente.
internal class FicheroRecursos {
private static global::System.Resources.ResourceManager resourceMan;
private static global::System.Globalization.CultureInfo resourceCulture;
[global::System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode")]
internal FicheroRecursos() {
}
……..
Primero haremos que la clase sea pública. Para ello, seleccionamos el fichero de recursos y lo podemos como “public”. De esta manera ponemos la clase como pública, pero el constructor sigue siendo “internal”.
Ya que el constructor sigue siendo “internal”, nos vemos obligados a crear una clase pública con un constructor público que nos haga de intermediario para poder acceder a la clase del fichero de recursos.
La clase intermediaria sería algo así: (esta es la clase que usaremos desde el XAML)
public class ClaseAccesoRecursos
{
public static FicheroRecursos ficheroRecursos = new FicheroRecursos();
public FicheroRecursos FicheroRecursos { get { return ficheroRecursos; } }
}
Una vez hecho, esto, tenemos que editar el fichero App.xaml y añadir la siguiente declaración: (SilverlightAppSample es el namespace de ClaseAccesoRecursos)
<Application.Resources>
<local:ClaseAccesoRecursos xmlns:local ="clr-namespace:SilverlightAppSample"
x:Key="ClaseAccesoRecursos" />
</Application.Resources>
Y ya por fin, podremos usar las cadenas dentro del código XAML. Si nuestra aplicación tiene un Label, la sintaxis para indicarle que use una cadena que está en un fichero de recursos sería así:
<dataInput:Label Content="{Binding FicheroRecursos.Cadena, Source={StaticResource ClaseAccesoRecursos}}"></dataInput:Label>
Ya para terminar, tenemos que configurar la aplicación web para que se adapte a la cultura del navegador y que la aplicación Silverlight haga lo mismo.
Como vimos en el
WebCast, en el fichero de configuración de la aplicación web podemos añadir lo siguiente:
<globalization uiCulture="Auto" culture="Auto"/>
Una vez hecho, editaremos el fichero aspx que sirve para probar la aplicación (SilverlightAppSampleTestPage.aspx) para que le pase como parámetro la cultura que tiene que utilizar.
Dentro del control object añadiremos lo siguiente:
<param name="uiculture" value="<%=System.Threading.Thread.CurrentThread.CurrentUICulture%>" />
<param name="culture" value="<%=System.Threading.Thread.CurrentThread.CurrentCulture%>" />
Y con esto ya está, ya hemos llegado al final. ¿Un poco lioso? Pues sí, pero de momento es lo que hay para Silverlight :-(
** cross-posting desde http://geeks.ms/blogs/ilanda
Hace unos días os hablaba de SEO Toolkit, una utilidad que permite analizar un website para optimizar el volumen y la calidad del tráfico que recibe desde los motores de búsqueda, como Bing o Google.
Jugando un poco con la utilidad, una cosa que vi es que uno de las situaciones de las que avisa la herramienta es de un exceso de redirecciones.
La razón es que el método Response.Redirect genera una respuesta HTTP 302 (redirección temporal). Los motores de búsqueda no siguen estos saltos, por lo que usar este tipo de redirecciones afecta negativamente al ranking de la página.
Al entender que es una redirección temporal, sólo indexa la primera, la URL desde la que se hace el redirect.
Con ASP.NET 4.0 tendremos un nuevo método llamado Response.RedirectPermanent(url) que puede usarse para realizar una redirección, pero generando una respuesta HTTP 301 (movido permanentemente).
Usar este método ayudará a los motores de búsqueda para entender que la redirección es permanente y usar la nueva URL, a la que se redirige, para que indexe sus contenidos.
Por ejemplo, si tuviéramos URLs antiguas que ya no son válidas y que lo único que hacen es redirigir a una URL nueva, usar este nuevo método sería mucho más adecuado.
Habrá que tenerlo en cuenta cuando empecemos con ASP.NET 4.0..
** cross-posting desde http://geeks.ms/blogs/ilanda
El próximo 3 de febrero, miércoles, tendrá lugar la siguiente charla del grupo de usuarios Artalde, esta vez hablando de algunas de las novedades de .NET Framework 4.0 para desarrolladores; una introducción a extensibilidad con MEF y paralelismo con TPL y PLINQ.
El lugar y hora, el de siempre; en la Universidad de Deusto, de 19:00 a 21:00 horas. El registro aquí.
En esta ocasión, será Luis Guerrero el que haga los honores y nos muestre las maravillas que nos trae la versión 4.0 del Framework…cremita de la buena!
Aquí os dejo la descripción completa de la charla:
En esta charlas veremos las novedades de las nos nuevas librerías que Microsoft incluye en .NET Framework para el desarrollo de extensibilidad de las aplicaciones, usado internamente por Microsoft para la extensibilidad de plug-ins en Visual Studio 2010, y cómo afrontar los problemas de concurrencia con Task Parallel Library.
MEF (Managed Extensibility Framework): El Framework de Extensibilidad para componentes administrados es una nueva librería incluida en el .NET Framework 4.0 que permite reutilizar aplicaciones y componentes. Usando MEF, las aplicaciones .NET pueden avanzar de ser estáticamente compiladas a ser dinámicamente compuestas en runtime. Una aplicación MEF está compuesta de Parts que se exportan, se importan y se componen. http://www.codeplex.com/mef/
Parallel Programming in the .NET Framework: Son una serie de nuevas APIs que permiten al desarrollador trabajar con el software y paralelizar los componentes para sacar el máximo partido a toda la potencia que los procesadores de varios cores ofrecen. Veremos TPL (Task Parallel Library) que es la librería para trabajar con Task, que son las nuevas unidades mínimas de paralización (nunca más threads), también veremos PLINQ que nos ofrece que la posibilidad de ejecutar nuestras consultas de LINQ tradicionales en varios cores y con mínimo impacto en la modificación de nuestra query y para finalizar veremos las nuestras estructuras de datos para la programación paralela, como pilas, colas y listas.
Lugar:
Universidad de Deusto
Edificio ESIDE, Aula de videoconferencia (2º piso)
Avda Universidades, 24
48007, BILBAO
** cross-posting desde http://geeks.ms/blogs/ilanda
Como seguro que muchos de vosotros ya sabréis ya están disponibles la mayoría de las charlas que se pudieron ver en el CodeCamp 2009.
Ya os comenté anteriormente que tuve el placer de participar hablando sobre RIA Services.
Pues aquí tenéis el video por si alguno le interesa, aunque tened en cuenta que la charla se hizo con la versión Beta.
El resto de videos y materiales podéis encontrarlos aquí.
** cross-posting desde http://geeks.ms/blogs/ilanda
Ayer mismo tuve el placer de participar en una charla organizada por SecondNug hablando sobre localización de aplicaciones.
Uno de los temas que salió, fue el tema de la traducción de recursos. Comenté que había una herramienta gratuita para la traducción de recursos que hace uso del sistema de traducción de Bing.
Aunque alguno ya lo comentó en la charla, la aplicación se llama “Scientia Resource Translator”.
Permite seleccionar un fichero de recursos y generar los ficheros de recursos en los idiomas seleccionadas. Soporta 20 idiomas.
Por cierto, para aquellos que estéis interesados recordad que podéis ver o descargaros el WebCast.
PD:En breve espero poder publicar alguna otra cosa más que quedo pendiente…
** cross-posting desde http://geeks.ms/blogs/ilanda
Hoy os hablo de una utilidad que aunque no es nueva, yo he descubierto recientemente y me parece bastante interesante; SEO Toolkit.
Esta utilidad permite analizar un website para optimizar el volumen y la calidad del tráfico que recibe desde los motores de búsqueda, como Bing o Google; para que los motores de búsqueda nos encuentren más fácil…
Una vez que lo instaléis, se añade como una opción más en la administración del Internet Information Server.
Una vez instalado, ya veréis que es muy sencillo utilizarlo.Sólo es necesario indicar la URL sobre la que hacer el análisis y ya está, a analizar los resultados y a optimizar tu site!
Por cierto, el WebSite que se analiza puede estar colgado en cualquier tipo de servidor, no tiene por qué ser IIS.
Espero que os sea de utilidad!
** cross-posting desde http://geeks.ms/blogs/ilanda
Hace poco que leía un post sobre cómo hacer un instalador haciendo uso de los proyectos de Setup de Visual Studio.
Es importante conocer que una cosa interesante que nos llegará con Visual Studio 2010 será la posibilidad de contar con una versión limitada del InstallShield, una de las herramientas más completas para la generación de instaladores.
Para mí una gran noticia, ya que es una solución que he usado en más de una ocasión y me parece bastante interesante, sobre todo si hay una versión gratuita.
Para descargarse la versión limitada de InstallShield se debe hacer desde el siguiente menú: File>New>Project>Other Project Types> Setup and Deployment>InstallShield 2010
Será necesario registrarse para poder descargarse la versión.
En el blog de Somasegar podéis encontrar el Post original dónde leí la noticia.
** cross-posting desde http://geeks.ms/blogs/ilanda
No sé qué extraña locura les ha movido, pero los chicos de Second Nug han vuelto a confiar en mí para realizar un WebCast, esta vez, hablando sobre localización de aplicaciones.
El próximo 19 de Enero, martes, tendré la oportunidad de hablaros sobre los aspectos principales a tener en cuenta para localizar nuestras aplicaciones.
El proceso de localización comprende todas las tareas asociadas al hecho de adaptar nuestro producto a una región o país específico; traducción de textos, formatos de fechas, monedas, unidades, etc.
Preparar tu aplicación para que pueda ser localizada no es una cuestión trivial y es importante conocer las implicaciones que este proceso supone y las diferentes alternativas con las que contamos.
En éste evento veremos de forma práctica las principales alternativas de las que disponemos para asegurarnos que nuestra aplicación esté preparada para ser localizada: Culturas, ficheros de recursos, cadenas en base de datos, trabajo con idiomas con caracteres extendidos, etc. ¿Estás preparado?
Para aquellos que estéis interesados en el evento os pongo unos enlaces que os resultarán útiles:
** cross-posting desde http://geeks.ms/blogs/ilanda
Después de echar la bronca a un “mal” compañero por no leerme y preguntarme sobre RIA Services, he decidido poneros un pequeño recopilatorio de los post que he escrito sobre WCF RIA Services y así el que quiera pueda ponerse un poco al día en esta tecnología.
Algunos post está hechos con las versiones previews pero en esencia es lo mismo. Espero que os sea de utilidad!
** cross-posting desde http://geeks.ms/blogs/ilanda
Ya un post anterior hablaba de cómo RIA Services se ha integrado dentro de WCF. En ese post anterior lo poníamos a prueba y veíamos cómo realmente es WCF, que no nos engañaban!
En este post toca ver en detalle algunas cosas sobre cómo se produce esta integración.
Una de las cosas que vimos es cómo 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, siendo la estructura del servicio la siguiente:
http://[hostname]/[namespacename]-[classname].svc
Por ejemplo, http://localhost:XXX/BusinessAplication1-Web-OrganizationService.svc (BussinessApplication1-Web es el nombre del namespace,cambiando el punto por un guión )
WCF RIA Services implementa su propio ServiceHost ( DomainServiceHost ), el cual expone tres endpoints; WebHttpBinding (REST + JSON), BasicHttpBinding (SOAP+XML) y BinaryHttpBinding (SOAP+Binario), siendo éste último el que se usa por defecto.
Si queremos cambiar el endpoint que se utiliza en la comunicación cliente-servidor, simplemente tenemos que indicar la dirección del endpoint que queremos usar al crear el DomainContext en el cliente:
OrganizationContext ctx = OrganizationContext(new Uri("BusinessApplication1-Web-OrganizationService.svc/soap", UriKind.Relative)));
Aunque el servicio se crea de forma implítica, comentaros que también lo podemos crear de forma explícita. Es tan fácil como crear un nuevo fichero llamando [namespacename]-[classname].svc, con el siguiente contenido:
<%@ ServiceHost Service="BusinessAplication1.Web.OrganizationService" Factory="System.Web.Ria.Services.DomainServiceHostFactory,
System.Web.Ria, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
De esta manera, tendremos un fichero svc creado físicamente, pero el funcionamiento de la aplicación no se ve alterado; por tanto, da igual crearlo que no crearlo. ¿Entonces?
Pues si nos vale con la funcionalidad que ofrece, pues no nos vale para nada, pero si queremos aprender cómo funciona o por qué no, personalizar el funcionamiento por defecto, sí que nos puede venir bien.
Como veis en el contenido del fichero svc, RIA Services usa un DomainServiceHostFactory, que no es más que una clase que extiende la clase ServiceHostFactory, y que lo que hace es proporcionar la funcionalidad que RIA Services necesita, por ejemplo, la de exponer los tres endpoints que comentábamos anteriormente.
Si quisiéramos crear nuevo propio comportamiento podría ser “tan fácil” como crearnos una nueva clase hija de ServiceHostFactory y ala, a personalizar todo lo que queramos :-)
El fichero svc quedaría algo así:
<%@ ServiceHost Service="BusinessAplication1.Web.OrganizationService"
Factory="BusinessAplication1.Web.CustomDomainServiceHostFactory" %>
Otra forma de hacerlo, en lugar de extender ServiceHostFactory, puede ser hacerlo de DomainServiceFactory. Por ejemplo, si quisiéramos hacer que nuestro servicio siempre funcione en binario y que no exponga los dos otros endpoints, ésta podría ser la solución más adecuada.
Los métodos que se usan dentro del método AddEndpoints para crear los endpoints los proporciona la clase base DomainServiceHostFactory.
public class CustomDomainServiceHostFactory:DomainServiceHostFactory
{
protected override System.ServiceModel.ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
return new CustomDomainServiceHost(serviceType, baseAddresses);
}
}
public class CustomDomainServiceHost:DomainServiceHost
{
public CustomDomainServiceHost(Type domainServiceType, params Uri[] baseAddresses)
: base(domainServiceType, baseAddresses)
{
}
protected override void AddEndpoints()
{
foreach (Uri uri in this.BaseAddresses)
{
//AddSoapWithBinaryEndpoint(uri);
AddRestWithJsonEndpoint(uri);
//AddSoapWithXmlEndpoint(uri);
}
}
}
** cross-posting desde http://geeks.ms/blogs/ilanda
[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.
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
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.
Por ejemplo, si indicamos que queremos ver los detalles y lo arrastramos, tendremos el siguiente resultado:
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.
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!
Como veis el trabajo se simplifica bastante y de una manera muy sencilla podemos conseguir cosas bastante interesantes…
** cross-posting desde http://geeks.ms/blogs/ilanda
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…
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:
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.
** cross-posting desde http://geeks.ms/blogs/ilanda
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.
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.
** cross-posting desde http://geeks.ms/blogs/ilanda