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

Question

Existe un lote de diferentes formas en que una aplicación Silverlight puede conectarse de nuevo a su servidor. Incluyendo

• WCF - Windows Communication Foundation
• REST (ver also)
• ADO.NET Data Services (o se trata simplemente descansar?)
• POX - Llanura XML antiguo (por ejemplo, XML básico)
• RIA services

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

(El problema es cuando el diseño de su primera aplicación de Silverlight saber qué usar cuando usted no tiene tiempo para aprender todo de ellos.)

Si tuviera que sustituir Silverlight con WPF en esta pregunta qué efecto ¿Tendría eso en tus respuestas? (Estoy asumiendo con WPF que debido a los servidores de seguridad y políticas de administración una conexión directa a la base de datos no es una opción.)

Answer 1

Mis dos (euros) centavos:

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

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 los métodos de servicio son de tipo GetCustomers, CreateInvoice, etc.

servicios RIA es una tecnología muy nueva que no he experimentado con aún, pero parece ser útil para crear aplicaciones en las que la parte de Silverlight y el servicio están estrechamente vinculados: usted define sus clases de servicio y métodos 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.

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

Answer 2

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 ofrece una gran 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 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.

Answer 3

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

RIA aún no está terminado. 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.

Sólo causar vale la pena mencionar, tener algunos enlaces:

http://blogs.msdn.com/brada/ Brad Abrams tiene un ejemplo que se está actualizando continuamente.

http://forums.silverlight.net/forums/53.aspx aquí es donde puede hacer preguntas.

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

Answer 4

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 básicas: - su interfaz de usuario cambiará más rápido que su capa de servicio. Los servicios RESTful estarán disponibles por varios años, Silverlight probablemente no lo haga - ¿Alguna vez sus servicios serán API? Bueno ... WCF REST es el camino a seguir - ¿Vas a mezclar código JavaScript y Silverlight? WCF REST te hará la vida más fácil - ¿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.

Answer 5

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 intentaron esto, pero si realmente se necesita se puede acceder al servicio RIA también con otros clientes, después de todo Servicios RIA se construyen en la parte superior de 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.