unable - ¿Dónde se encuentran los servicios WCF y ADO.Net Data?
no se pueden recuperar metadatos mvc (3)
Estoy un poco confundido acerca de ADO.Net Data Services.
¿Es solo para crear 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 pretendo 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?
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.
En mi opinión, los servicios de datos ADO.Net son para crear servicios tranquilos que están estrechamente alineados con su modelo de dominio, es decir, los modelos mismos se publican en lugar de decir alguna forma de DTO, etc.
Usarlo para servicios de estilo RPC parece un mal ajuste, aunque desafortunadamente incluso algunas funciones muy básicas como poder 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, para que pueda visualizar una cuadrícula paginada, etc.
WCF 3.5 pre-SP1 era una plataforma RESTful bastante débil, con SP1 mejorado en ambas plantillas URI y con la disponibilidad de soporte ATOMPub, de modo que se está volviendo más capaz, pero realmente no ofrecen ninguna solución elegante para admitir, digamos JSON , XML, ATOM o incluso algo más esotérico como payload como CSV simultáneamente, salvo tener que usar la reescritura de URL y diferentes extensiones, munging de nombres de métodos, 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 puede hacer transición de estado navegando a través de ellos, es un poco torpe. Los servicios de datos ADO.Net hacen esto bastante bien con su AtomPub apoyo sin embargo.
Mi recomendación sería usar servicios web donde naturalmente se trata de servicios y se impongan estrictos límites de servicio. Utilice los servicios de datos ADO.Net para clientes ricos en estilo web (sitios web, ajax, silverlight) donde la capacidad de compilación de las consultas URL puede salvar un mucha fontanería y su modelo de dominio es bastante básico ... y despliegue 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 la utilicen. consumir en una plataforma social, etc.
Mi 2 digno!
En realidad, hay opciones para filtrar y omitir para obtener la característica de página entre otros.