wcf silverlight rest wcf-ria-services wcf-data-services

¿Cómo elijo entre los servicios WCF, REST, POX y RIA para una nueva aplicación Silverlight?



wcf-ria-services wcf-data-services (5)

Hay muchas formas diferentes en que una aplicación Silverlight puede conectarse a su servidor. Incluso

Para cada uno de ellos, indique para qué sirve y cuándo lo usaría o no. No busco un gran nivel de detalles solo un conjunto de "reglas generales" para elegir entre ellos.

(El problema es cuando diseñas tu primera aplicación de Silverlight sabiendo qué usar cuando no tienes tiempo para aprender todas).

Si tuviera que reemplazar a Silverlight con WPF en esta pregunta, ¿qué efecto tendría en sus respuestas? (Asumo con WPF que debido a los firewalls y las políticas de administración, una conexión directa a la base de datos no es una opción).

Creo que nunca volvería a utilizar POX. Si escribe WCF para que el servicio en sí sea independiente del enlace y se realice el enlace en los archivos de configuración, entonces WCF es bastante agnóstico sobre el transporte y el protocolo. Puede hacer SOAP, JSON, REST o su propia forma de serialización binaria. Todo esto está en el enlace. Internamente, WCF solo especifica qué se expone en términos de operación y contratos de datos (todos definidos por clase, método y atributos de propiedad). WCF le brinda una tremenda flexibilidad en este sentido, con más por venir en 2010.

Desde el lado de Silverlight, WCF requiere que escriba un código de plomería. .NET frameowrk tiene las herramientas para construir el proxy en su proyecto de Silverlight, pero debe estar preparado para manejar todas las respuestas de WCF de forma asincrónica, y el proxy no puede detectar las excepciones lanzadas por el servicio.

.NET RIA Services oculta todo esto. Utiliza WCF debajo de las cubiertas, pero eso está completamente oculto. No tiene que escribir un código asíncrono. Define la validación una vez, principalmente de forma declarativa, y funciona tanto en el lado del servidor como en el lado del cliente. La versión 1 se destinará a Silverlight, por lo que no obtendrá la versatilidad para utilizar el servicio en otro lugar. Se supone que ese alcance se ampliará en versiones posteriores.

No sé lo suficiente sobre ADO.NET Data Services para comparar. Sospecho que la respuesta dependerá de si desea exponer sus datos a algo más que el uso de Silverlight.

.NET RIA Services parece la dirección en la que me gustaría ir (analizando estos problemas yo mismo, con una gran aplicación en mente). Los grandes problemas para mí serán implementar una gran colección de funcionalidades en la capa de servicios y no poder codificar directamente en la capa de acceso a los datos (tenemos que poder ejecutar en SQL Server u Oracle).

Usar WPF en lugar de Silverlight lo cambia todo, dependiendo de dónde residan sus datos. Es como la vieja pregunta de Winforms vs. ASP.NET. Con WPF, está creando una aplicación cliente de Windows, y no necesita utilizar ninguna forma de interfaz de datos basada en el servicio, a menos que su acceso a los datos lo obligue a hacerlo. Igual querrá separar datos y negocios del código de presentación, utilizando MVVM, MVC o MVP. Aparte de eso, tiene la opción de tratar el acceso a los datos como una capa, en lugar de un nivel independiente wholy.

Mis dos (euro) centavos:

WCF parece ser el más adecuado cuando el servicio se puede ver como la capa empresarial de la aplicación, es decir, cuando su servicio tiene operaciones "inteligentes" como "CalcularDiscountForClient" .

ADO.NET Data Services (de hecho, solo una implementación REST) ​​parece apropiado cuando su aplicación está básicamente centrada en datos y el servicio es simplemente un front-end para la base de datos. Es decir, todos sus métodos de servicio son de tipo GetCustomers, CreateInvoice, etc.

Los servicios de RIA son una tecnología muy nueva con la que aún no he experimentado, pero parece ser útil para crear aplicaciones en las que la pieza de Silverlight y el servicio están estrechamente vinculados: usted define sus clases y métodos de servicio en el proyecto de servicio, y se replican automáticamente en el proyecto de Silverlight en tiempo de diseño. Además, puede definir métodos de "acción" al estilo WCF y métodos de "datos" al estilo de los Servicios de Datos ADO.NET. Parece prometedor.

Use POX si existe la posibilidad de que cambie la parte del cliente de Silverlight a cualquier otra tecnología (por ejemplo, HTML + AJAX) en el futuro, ya que es la opción más interoperable.

Acerca de las diferencias para WPF, lo único que puedo pensar es que, para el acceso a datos, siempre que sea posible utilizaría conexiones directas de datos ADO.NET (correctamente integradas en una capa de acceso a datos, LINQ a SQL o similar) en lugar de ADO.NET Servicios de datos, ya que es mucho más flexible. De todos modos, debo decir que nunca he desarrollado nada en WPF.

Si desea crear una aplicación de Silverlight y no le importan otros clientes, entonces elegiría los servicios de RIA. Es bastante fácil de usar y no tiene que preocuparse de cómo se realiza la conexión desde el cliente (es decir, no es necesaria la configuración del lado del cliente). RIA también genera clases para todas sus entidades en el cliente e incluso puede compartir su propio código de "servidor" con el cliente si es necesario (útil para enumeraciones o métodos de extensión).

Observaciones:

  • Nunca lo intenté, pero si realmente lo necesita, puede acceder al Servicio RIA también con otros clientes, después de que todos los Servicios RIA se construyan sobre los servicios de WCF.
  • No entiendo muy bien las preocupaciones de seguridad de Akash Kava. Puede (y debe) controlar la seguridad en el servidor como lo haría con cualquier otro servicio.

Usamos RIA, y esa es la única de las opciones que conozco, pero sí lo sé, así que aquí están algunos de mis pensamientos.

RIA no ha terminado todavía. Está siendo trabajado. Si planea terminar pronto y le preocupa tener que respaldar algo que tiene un potencial de cambio considerable, entonces es posible que desee considerar otras opciones. Si se trata de un proyecto nuevo, y lo va a respaldar durante mucho tiempo, es probable que RIA sea más fácil de usar.

Habiendo dicho eso, creo que no habrá muchos cambios en la forma en que funciona la Vista previa de Julio de RIA y la forma en que funcionará una versión final. Además, el nivel de soporte parece sugerir que esto se convertirá en "The Way" para hablar con un servidor en Silverlight.

Solo porque vale la pena mencionar, tener algunos enlaces:

http://blogs.msdn.com/brada/ Brad Abrams tiene un ejemplo que continuamente actualiza.

http://forums.silverlight.net/forums/53.aspx es donde vas a hacer preguntas.

http://www.riaservicesblog.com/Blog/ Colin Blair conoce sus cosas, y es muy útil.

WCF es el estándar de Microsoft para la comunicación de servicios. Recomiendo encarecidamente a cualquiera que cree una capa de servicio utilizando WCF Web API (utiliza WCF, pero específicamente diseñada para REST), que saldrá en abril de 2012. WCF Web APIs se encuentra actualmente en modo de vista previa.

Recuerde estas reglas generales: su UI cambiará más rápido que su capa de servicio. Los servicios RESTful estarán presentes en varios años, Silverlight probablemente no lo hará. ¿Sus servicios serán alguna vez API? Bueno ... WCF REST es el camino a seguir. ¿Vas a mezclar código JavaScript y Silverlight? WCF REST te facilitará la vida: tendrás un componente móvil (ya que Silverlight no se ejecutará en iOS o Android) ... Se prefiere REST.

No adapte a la tecnología, sino a la aplicación como un todo.