Creo que la discusión sobre el uso orientado a servicios programáticos frente a la interacción humana es clara.
Pero si tuviera que crear una aplicación que haga uso tanto de una API programática como de un sitio web que haga uso de los datos conectados por la misma API, ¿se inclinaría por el uso de solo ASP.NET?
¿Qué tan fácil es integrar ASP.NET y WCF para trabajar en la misma aplicación?
Respuestas:
En cuanto a escribir una aplicación que aproveche tanto ASP.NET/MVC como WCF, no es genial. Es posible que WebAPI haya mejorado las cosas, pero en un proyecto que estoy familiarizado con el uso de WCF y MVC en la misma aplicación, terminaron manteniendo dos conjuntos diferentes de modelos para representar los mismos conceptos: uno para el código WCF y otro para el MVC código. Puede imaginarse todos los mapeadores que tuvieron que escribir para traducir cosas entre los dos modelos: había muchas líneas de código que podrían haberse evitado.
Parte de por qué sucedió esto es que los objetos de solicitud y respuesta de WCF deben anotarse con [DataContract] y sus propiedades con [DataMember], mientras que MVC no lo requiere. Idiomatic MVC, por otro lado, va a querer ViewModels, que tienen diferentes objetivos que WCF DataContracts. Por supuesto, es posible que el uso de dos conjuntos completos de objetos de dominio tenga más que ver con la ley de Conway que el conflicto entre WCF y MVC, pero vale la pena señalar que WCF y MVC tienen diferentes objetivos y requisitos en cuanto a salida y entrada.
Personalmente, soy partidario de desarrollar una API de back-end orientada a servicios simple pero poderosa, particularmente cuando es posible que desee múltiples clientes. Creo que el advenimiento de los excelentes marcos JavaScript MVVM y micro-MVC lo convierte en una opción natural, ya que escribir código de aplicación utilizando BackboneJS , KnockoutJS y otros permite un entorno de desarrollo capaz. Luego puede consumir el back-end en el micro MVC de su elección para construir su aplicación web, o en un cliente móvil, y sus socios también pueden consumir la misma API de forma remota.
Sugerencia
WebAPI o Service Stack pueden ser buenos candidatos para construir su API back-end. Recomiendo Service Stack, ya que lo he estado usando durante los últimos meses y he encontrado que es un excelente reemplazo para WCF. Actualmente estoy escribiendo una serie de tutoriales sobre la pila de servicios en mi blog .
El grupo que mantiene la pila de servicios ha publicado una aplicación de ejemplo utilizando el marco para desarrollar un clon similar a StackOverflow que muestra un patrón de desarrollo que creo que es especialmente convincente. Se trata de un back-end de servicios basados en modelos simples que podría imaginarse consumido por un sitio web de MVC, una aplicación móvil o casi cualquier otra cosa fácilmente. Los objetivos de diseño de ServiceStack claramente fomentan un patrón que debería conducir a un menor acoplamiento entre el cliente y el servidor. La idea es evitar API habladores con llamadas como GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)a favor de menos métodos. Puede implementar lo mismo en la pila de servicios de esta manera:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
El beneficio, a mis ojos, es que en lugar de tener su extensión lógica de negocio a lo largo de montones y montones de métodos distintos GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), todo en un solo lugar. Esto debería conducir a un código más mantenible.
Casualmente, Stack Exchange contrató al autor original de Service Stack . Él continúa comprometiéndose activamente con el proyecto Service Stack.
Me gustan especialmente las colas de mensajes para ciertas cosas, y aunque WCF lo permitió, WebAPI no. ServiceStack permite invocar el mismo servicio web a través de MQ. Para obtener más información sobre esto, consulte el Host Redis MQ en: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb ha respondido correctamente IMO pero quería extender esa respuesta. La API web ASP.NET que se encuentra actualmente en etapa beta y un proyecto OSS es el marco más cercano que está buscando.
La breve descripción del producto es la siguiente (citado de la página API web de ASP.NET ):
ASP.NET Web API es un marco que facilita la creación de servicios HTTP que llegan a una amplia gama de clientes, incluidos navegadores y dispositivos móviles. ASP.NET Web API es una plataforma ideal para construir aplicaciones RESTful en .NET Framework.
En cuanto a la aplicación cliente que podría estar utilizando para consumir su API web, ciertamente no tiene que ser una aplicación ASP.NET. Puede consumir su API con una página HTML estática utilizando JavaScript. Puede hacerlo fácilmente con algunas bibliotecas JavaScript útiles, como jQuery.
Por otro lado, ciertamente puede consumir su API en el sitio del servidor en cualquier aplicación ASP.NET. El proyecto de API web también introdujo una nueva API de cliente HTTP .NET llamada HttpClient que facilita el consumo de servicios HTTP.
En general, aquí hay un buen conjunto de recursos para que pueda comenzar:
Introducción a la API web de ASP.NET: tutoriales, videos, muestras
Recuerde que el proyecto todavía está en su etapa beta. Le recomiendo que siga el blog de Henrik F Nielsen donde publica información sobre las últimas actualizaciones inéditas del proyecto. Puede alcanzar el código fuente del proyecto y el flujo de desarrollo dentro del proyecto ASP.NET Web Stack .
Creo que la guía actual es usar MVC Web API en lugar de WCF para REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
El modelo de desarrollo está bastante cerca y evita la configuración a veces desagradable de WCF.