Penso que a discussão sobre uso orientado a serviços programáticos versus interação humana é clara.
Mas, se eu fosse criar um aplicativo que fizesse uso de uma API programática e de um site que fizesse uso dos dados conectados pela mesma API, isso favorece o uso apenas do ASP.NET?
Quão fácil é integrar o ASP.NET e o WCF para trabalhar no mesmo aplicativo?
Respostas:
Quanto a escrever um aplicativo que aproveite o ASP.NET/MVC e o WCF, isso não é ótimo. O WebAPI pode ter melhorado, mas em um projeto que estou familiarizado com o uso do WCF e do MVC no mesmo aplicativo, eles acabaram mantendo dois conjuntos diferentes de modelos para representar os mesmos conceitos - um para o código WCF e outro para o MVC código. Você pode imaginar todos os mapeadores que eles tiveram que escrever para traduzir as coisas entre os dois modelos - havia muitas linhas de código ali que poderiam ter / deveriam ter sido evitadas.
Parte do motivo disso aconteceu é que os objetos de solicitação e resposta do WCF devem ser anotados com [DataContract] e suas propriedades com [DataMember], enquanto o MVC não exige isso. O MVC da Idiomatic, por outro lado, vai querer os ViewModels, que têm objetivos diferentes dos WCF DataContracts. Obviamente, é possível que o uso de dois conjuntos completos de objetos de domínio tenha mais a ver com a lei de Conway do que o conflito entre WCF e MVC, mas vale ressaltar que o WCF e o MVC têm objetivos e requisitos diferentes em termos de saída e entrada.
Pessoalmente, sou parte integrante do desenvolvimento de uma API de back-end simples, mas poderosa, orientada a serviços, especialmente quando você pode desejar vários clientes. Eu acho que o advento de excelentes estruturas JavaScript MVVM e micro-MVC faz disso uma escolha natural, pois escrever código de aplicativo usando BackboneJS , KnockoutJS e outros permite um ambiente de desenvolvimento capaz. Em seguida, você pode consumir o back-end no micro MVC de sua escolha para criar seu aplicativo Web ou em um cliente móvel, e seus parceiros também podem consumir a mesma API remotamente.
Sugestão
O WebAPI ou o Service Stack podem ser bons candidatos para criar sua API de back-end. Eu recomendo o Service Stack, pois o tenho usado nos últimos meses e achei um excelente substituto para o WCF. Atualmente, estou escrevendo uma série de tutoriais sobre a pilha de serviços no meu blog .
O grupo que mantém a pilha de serviços postou um aplicativo de exemplo usando a estrutura para desenvolver um StackOverflow como o clone, que mostra um padrão de desenvolvimento que acredito ser especialmente atraente. Envolve um back-end simples de serviços baseados em modelo que você pode imaginar sendo consumido por um site MVC, um aplicativo móvel ou qualquer outra coisa facilmente. As metas de design do ServiceStack incentivam claramente um padrão que deve levar a menos acoplamento entre cliente e servidor. A idéia é evitar APIs tagarelas com chamadas como a GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)favor de menos métodos. Você pode implementar a mesma coisa na pilha de serviços como esta:
[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();
}
}
O benefício, aos meus olhos, é que em vez de ter a sua propagação lógica de negócios ao longo de muitos e muitos métodos distintos GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), é tudo em um só lugar. Isso deve levar a um código mais sustentável.
Coincidentemente, o Stack Exchange contratou o autor original do Service Stack . Ele continua comprometendo - se ativamente com o projeto Service Stack.
Gosto particularmente de filas de mensagens para certas coisas - e, embora o WCF permita isso, o WebAPI não. O ServiceStack permite que o mesmo serviço da Web seja chamado via MQ. Para obter mais informações, consulte o Redis MQ Host em: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@ tzerb respondeu corretamente IMO, mas eu queria estender essa resposta. A API da Web do ASP.NET, que está atualmente no estágio beta e um projeto OSS, é a estrutura mais próxima que você está procurando.
A descrição resumida do produto é a seguinte (citada na página API da Web do ASP.NET ):
A API da Web do ASP.NET é uma estrutura que facilita a criação de serviços HTTP que atingem uma ampla variedade de clientes, incluindo navegadores e dispositivos móveis. A API da Web do ASP.NET é uma plataforma ideal para criar aplicativos RESTful no .NET Framework.
Quanto ao aplicativo cliente que você pode estar usando para consumir sua API da web, ele certamente não precisa ser um aplicativo ASP.NET. Você pode consumir sua API com uma página HTML estática usando JavaScript. Você pode fazer isso facilmente com algumas bibliotecas JavaScript úteis, como o jQuery.
Por outro lado, você certamente pode consumir sua API no site do servidor em qualquer aplicativo ASP.NET. O projeto da API da Web também introduziu uma nova API do cliente HTTP .NET chamada HttpClient, que facilita o consumo de serviços HTTP.
Em geral, eis um bom conjunto de recursos para você começar:
Introdução à API da Web do ASP.NET - Tutoriais, vídeos, amostras
Lembre-se de que o projeto ainda está em fase beta. Eu recomendo que você siga o blog de Henrik F Nielsen, onde ele publica informações sobre as últimas atualizações não lançadas no projeto. Você pode acessar o código-fonte do projeto e o fluxo de desenvolvimento dentro do projeto ASP.NET Web Stack .
Acho que a orientação atual é usar o MVC Web API em vez do WCF para REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
O modelo de desenvolvimento está bem próximo e você ignora a configuração às vezes desagradável do WCF.