Penso che la discussione sull'uso orientato al servizio programmatico rispetto all'interazione umana sia chiara.
Ma se dovessi creare un'applicazione che utilizza sia un'API programmatica che un sito Web che utilizza i dati collegati dalla stessa API, si appoggia il favore all'utilizzo solo di ASP.NET?
Quanto è facile integrare ASP.NET e WCF per lavorare sulla stessa applicazione?
Risposte:
Per quanto riguarda la scrittura di un'applicazione che sfrutta sia ASP.NET/MVC che WCF, non è eccezionale. WebAPI potrebbe avere migliorato le cose, ma in un progetto che conosco stava usando WCF e MVC nella stessa app, hanno finito per mantenere due diversi set di modelli per rappresentare gli stessi concetti: uno per il codice WCF e uno per MVC codice. Potete immaginare tutti i mappatori che dovevano scrivere per tradurre le cose tra i due modelli: c'erano molte righe di codice che avrebbero potuto / avrebbero dovuto essere evitate.
Parte del motivo per cui ciò è accaduto è che gli oggetti di richiesta e risposta WCF devono essere annotati con [DataContract] e le loro proprietà con [DataMember], mentre MVC non lo richiede. D'altra parte MVC idiomatico vorrà ViewModels, che hanno obiettivi diversi rispetto a WCF DataContracts. Ovviamente, è possibile che l'uso di due set completi di oggetti di dominio abbia più a che fare con la legge di Conway che WCF e MVC in conflitto, ma vale la pena sottolineare che WCF e MVC hanno obiettivi e requisiti diversi in termini di output e input.
Personalmente, sono parziale allo sviluppo di un'API back-end orientata ai servizi semplice ma potente, in particolare quando potresti desiderare più client. Penso che l'avvento dell'eccellente JavaScript MVVM e dei framework micro-MVC la renda una scelta naturale, come scrivere codice applicativo usando BackboneJS , KnockoutJS e altri consente un ambiente di sviluppo capace. Puoi quindi utilizzare il back-end nel micro MVC di tua scelta per creare la tua app Web o su un client mobile e i tuoi partner potrebbero utilizzare anche la stessa API in remoto.
Suggerimento
WebAPI o Service Stack potrebbero essere buoni candidati per la creazione dell'API back-end. Consiglio Service Stack, poiché lo uso da alcuni mesi e lo trovo un eccellente sostituto di WCF. Attualmente sto scrivendo una serie di tutorial sullo stack di servizi sul mio blog .
Il gruppo che gestisce lo stack di servizi ha pubblicato un'applicazione di esempio che utilizza il framework per sviluppare un clone di StackOverflow come un modello di sviluppo che credo sia particolarmente convincente. Implica un semplice back-end di servizi basato su modelli che potresti immaginare di essere consumato da un sito Web MVC, un'app mobile o qualsiasi altra cosa facilmente. Gli obiettivi di progettazione di ServiceStack incoraggiano chiaramente un modello che dovrebbe portare a un minore accoppiamento tra client e server. L'idea è di evitare le API chiacchieroni con chiamate come GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)a favore di un minor numero di metodi. È possibile implementare la stessa cosa nello stack di servizi in questo modo:
[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();
}
}
Il beneficio, ai miei occhi, è che invece di avere il vostro diffusione logica di business fuori sopra un sacco di metodi separati GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), è tutto in un unico luogo. Ciò dovrebbe portare a un codice più gestibile.
Per coincidenza, Stack Exchange ha assunto l' autore originale dello Stack di servizio . Continua a impegnarsi attivamente nel progetto di Service Stack.
Sono particolarmente affezionato alle code di messaggi per alcune cose - e mentre WCF lo ha permesso, WebAPI no. ServiceStack consente di invocare lo stesso servizio Web tramite MQ. Per maggiori informazioni su questo vedi l'host Redis MQ su: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb ha risposto correttamente all'IMO ma volevo estendere quella risposta. L'API Web ASP.NET che è attualmente in fase beta e un progetto OSS è il framework più vicino che stai cercando.
La breve descrizione del prodotto è la seguente (citata dalla pagina API Web ASP.NET ):
L'API Web ASP.NET è un framework che semplifica la creazione di servizi HTTP che raggiungono un'ampia gamma di client, inclusi browser e dispositivi mobili. L'API Web ASP.NET è una piattaforma ideale per la creazione di applicazioni RESTful su .NET Framework.
Per quanto riguarda l'applicazione client che potresti utilizzare per utilizzare l'API Web, sicuramente non deve essere un'applicazione ASP.NET. Puoi utilizzare l'API con una pagina HTML statica utilizzando JavaScript. Puoi farlo facilmente con alcune utili librerie JavaScript come jQuery.
D'altra parte, puoi certamente consumare la tua API sul sito del server in qualsiasi applicazione ASP.NET. Il progetto API Web ha inoltre introdotto una nuova API client .NET .NET denominata HttpClient che semplifica l'utilizzo dei servizi HTTP.
In generale, ecco un buon set di risorse per iniziare:
Introduzione all'API Web ASP.NET - Tutorial, video, esempi
Ricorda che il progetto è ancora nella fase beta. Ti consiglio di seguire il blog di Henrik F Nielsen dove pubblica informazioni sugli ultimi aggiornamenti inediti per il progetto. È possibile raggiungere il codice sorgente del progetto e il flusso di sviluppo all'interno del progetto Stack Web ASP.NET .
Penso che l'attuale indizio sia usare l'API Web MVC invece di WCF per REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
Il modello di sviluppo è piuttosto vicino e si ignora la configurazione a volte brutta di WCF.