ASP.NET MVC vs WCF per API REST + utilizzo pagina web

Per quanto riguarda la scrittura di un'applicazione che sfrutta sia ASP.NET/MVC che WCF, non è eccezionale. WebAPI potrebbe aver migliorato le cose, ma in un progetto che ho familiarità con l'utilizzo di 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 l'MVC codice. Puoi immaginare tutti i mappatori che hanno dovuto scrivere per tradurre le cose tra i due modelli: c'erano molte righe di codice che avrebbero potuto / dovrebbero essere evitate.

Parte del motivo per cui ciò è accaduto è che gli oggetti di richiesta e risposta WCF dovrebbero essere annotati con [DataContract] e le loro proprietà con [DataMember], mentre MVC non richiede questo. Idiomatic MVC d'altra parte vorrebbe ViewModels, che hanno obiettivi diversi rispetto a WCF DataContracts. Naturalmente, è possibile che l'uso di due set completi di oggetti dominio abbia più a che fare con la legge di Conway rispetto a WCF & MVC in conflitto, ma vale la pena sottolineare che WCF e MVC hanno obiettivi e requisiti diversi per quanto riguarda l'output e l'input.

Personalmente, sono parziale nello sviluppo di un'API back-end semplice ma potente orientata ai servizi, in particolare quando potresti volere più client. Penso che l'avvento di eccellenti MVVM JavaScript e framework micro-MVC rende questa una scelta naturale, come scrivere il codice dell'applicazione usando BackboneJS , KnockoutJS e altri consentono 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 anche utilizzare la stessa API da remoto.

Suggerimento

Sia WebAPI o Stack di servizio potrebbero essere buoni candidati per la creazione dell'API back-end. Raccomando Service Stack, dato che lo sto usando da alcuni mesi e ho trovato che sia un eccellente sostituto di WCF. Al momento sto scrivendo una serie di tutorial sullo stack di servizio sul mio blog .

Il gruppo che gestisce lo stack di servizi ha pubblicato una applicazione di esempio utilizzando il framework per sviluppare un clone StackOverflow simile a un modello di sviluppo che credo sia particolarmente avvincente. Si tratta di un semplice back-end di servizi basati su modelli che potresti immaginare di essere consumati da un sito Web MVC, da un'app per dispositivi mobili o semplicemente da qualsiasi altra cosa. 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 API chiacchierate con chiamate come GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm) a favore di un minor numero di metodi. Potresti implementare la stessa cosa nello stack di servizio 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 vantaggio, secondo i miei occhi, è che invece di avere la tua logica aziendale distribuita su molti e diversi metodi separati GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm) , GetCustomersInRegion(int regionId) , GetCustomersWithSearchTerm(string searchTerm) , GetCustomers() , è tutto in un posto. Ciò dovrebbe portare a un codice più gestibile.

Per coincidenza, Stack Exchange ha assunto lo Stack di servizio originale autore . Continua a impegnarsi attivamente nel progetto Stack di servizi.

Sono particolarmente affezionato alle code dei messaggi per determinate cose - e mentre WCF lo consente, WebAPI no. ServiceStack consente di richiamare 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 la 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 (citato dalla pagina API Web ASP.NET ):

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

Per quanto riguarda l'applicazione client che potresti utilizzare per utilizzare la tua API Web, certamente non deve essere un'applicazione ASP.NET. Puoi utilizzare la tua API con una pagina HTML statica utilizzando JavaScript. Potresti 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 HTTP .NET chiamata HttpClient che semplifica l'utilizzo dei servizi HTTP.

In generale, ecco un buon set di risorse per iniziare:

Guida introduttiva all'API Web ASP.NET - Esercitazioni, video, esempi

Ricorda che il progetto è ancora nella fase beta. Ti consiglio di seguire il blog Henrik F Nielsen in cui pubblica le informazioni sugli ultimi aggiornamenti inediti da proiettare. Puoi raggiungere il codice sorgente del progetto e il flusso di sviluppo all'interno del progetto Stack Web ASP.NET .

Penso che il criterio corrente sia utilizzare MVC Web API invece di WCF per REST. link

Il modello di sviluppo è piuttosto vicino e si ignora la configurazione talvolta sporca di WCF.