2008-09-08 18 views
5

Estoy un poco confundido acerca de ADO.Net Data Services.¿Dónde se encuentran los servicios WCF y ADO.Net Data?

¿Está destinado únicamente a la creación de servicios web RESTful? Sé que WCF comenzó en el mundo SOAP pero ahora escuché que tiene un buen apoyo para REST. Lo mismo ocurre con los servicios de datos ADO.Net donde puede hacer que funcione en un modelo RPC si no puede ver todo desde una vista orientada a recursos.

Al menos de las demostraciones que vi recientemente, parece que ADO.Net Data Services se basa en la pila de WCF en el servidor. Por favor, corríjame si estoy equivocado.

No tengo la intención de comenzar un debate REST vs SOAP, pero creo que las cosas ya no son tan claras.

¿Alguna sugerencia o guía sobre qué usar dónde?

Respuesta

2

En mis servicios de datos vista ADO.Net es para la creación de servicios de descanso que están estrechamente alineados con su modelo de dominio, es decir, los modelos mismos son publicados en lugar de decir alguna forma de DTO etc.

Su uso para RPC los servicios de estilo parecen un mal ajuste, aunque desafortunadamente incluso algunas funciones muy básicas como la capacidad de realizar recuentos filtrados, etc. no están disponibles, lo que a menudo significa que terminará usando algún RPC solo para cumplir con los requisitos de sus clientes, es decir, puede mostrar una cuadrícula paginada, etc.

WCF 3.5 pre-SP1 era una plataforma RESTful bastante débil, con SP1 las cosas han mejorado en ambas plantillas URI y con la disponibilidad de A El soporte de TOMPub es cada vez más capaz, pero en realidad no ofrecen ninguna solución elegante para admitir, por ejemplo, JSON, XML, ATOM o incluso algo más esotérico como la carga útil como CSV simultáneamente, salvo tener que utilizar la reescritura de URL y diferentes extensión, nombre del método, munging, etc., en lugar de simplemente seleccionar un serializador/deserializador basado en los encabezados de la solicitud.

Con WCF sigue siendo difícil crear servicios que funcionen de una manera más natural, es decir, donde los recursos incluyen urls, y se puede pasar de estado navegándolos - es un poco torpe - los servicios de datos ADO.Net hacen esto bastante bien con su soporte de AtomPub sin embargo.

Mi recomendación sería usar servicios web donde naturalmente se trata de servicios y se aplican estrictos límites de servicio, use los servicios de datos ADO.Net para clientes web ricos (sitios web, ajax, silverlight) donde la compibilidad de la URL las consultas pueden ahorrar mucha fontanería y su modelo de dominio es bastante básico ... y desplegar su propia capa REST (quizás usando un marco MVC como punto de partida) si necesita control total sobre la información, es decir, si está publicando una API para que otros desarrolladores consuman en una plataforma social, etc.

¡Mi 2ø vale la pena!

1

El uso del enlace de reposo de WCF es muy válido cuando se trabaja con código que no interactúa con ninguna base de datos. Los verbos HTTP no siempre tienen que ir contra un proveedor de datos.

+0

punto muy válido .. –

0

En realidad, hay opciones para filtrar y omitir para obtener la característica de página entre otros.

See here:

Cuestiones relacionadas