Saya pikir diskusi untuk penggunaan berorientasi layanan terprogram vs interaksi manusia jelas.
Tetapi jika saya membuat aplikasi yang menggunakan baik API terprogram dan situs web yang menggunakan data yang terhubung oleh API yang sama, apakah itu condong ke arah menggunakan hanya ASP.NET?
Seberapa mudah mengintegrasikan ASP.NET dan WCF untuk bekerja pada aplikasi yang sama?
Jawaban:
Sejauh menulis satu aplikasi yang memanfaatkan ASP.NET/MVC dan WCF, itu tidak bagus. WebAPI mungkin telah memperbaiki masalah, tetapi dalam satu proyek saya terbiasa dengan yang menggunakan WCF dan MVC di aplikasi yang sama, mereka akhirnya mempertahankan dua set model yang berbeda untuk mewakili konsep yang sama - satu untuk kode WCF dan satu untuk MVC kode. Anda dapat membayangkan semua pemetaan yang harus mereka tulis untuk menerjemahkan hal-hal di antara kedua model - ada banyak baris kode di sana yang dapat / seharusnya dihindari.
Bagian dari mengapa ini terjadi adalah bahwa objek permintaan dan respons WCF harus dijelaskan dengan [DataContract] dan propertinya dengan [DataMember], sedangkan MVC tidak memerlukan ini. MVC idiomatik di sisi lain akan menginginkan ViewModels, yang memiliki tujuan berbeda dari WCF DataContracts. Tentu saja, mungkin bahwa penggunaan dua set penuh objek domain lebih berkaitan dengan hukum Conway daripada WCF & MVC yang saling bertentangan, tetapi patut menunjukkan bahwa WCF dan MVC memiliki tujuan dan persyaratan yang berbeda sejauh output dan input.
Secara pribadi, saya ingin mengembangkan API back end yang sederhana namun kuat, terutama ketika Anda menginginkan banyak klien. Saya pikir munculnya kerangka kerja MVVM JavaScript dan mikro-MVC yang sangat baik menjadikan ini pilihan alami, karena menulis kode aplikasi menggunakan BackboneJS , KnockoutJS , dan lainnya memungkinkan lingkungan pengembangan yang mampu. Anda kemudian dapat mengkonsumsi ujung belakang di MVC mikro pilihan Anda untuk membangun aplikasi web Anda, atau pada klien seluler, dan mitra Anda mungkin mengkonsumsi API yang sama dari jarak jauh juga.
Saran
Baik WebAPI atau Service Stack mungkin merupakan kandidat yang baik untuk membangun API back end Anda. Saya merekomendasikan Service Stack, karena saya telah menggunakannya selama beberapa bulan terakhir dan telah menemukan itu menjadi pengganti yang sangat baik untuk WCF. Saat ini saya sedang menulis seri tutorial tentang tumpukan layanan di blog saya .
Grup yang mengelola tumpukan layanan telah memposting contoh aplikasi menggunakan kerangka kerja untuk mengembangkan klon seperti StackOverflow yang menunjukkan pola pengembangan yang saya percaya sangat menarik. Ini melibatkan layanan sederhana berbasis model yang dapat Anda bayangkan sedang dikonsumsi oleh situs web MVC, aplikasi seluler, atau apa pun dengan mudah. Tujuan desain ServiceStack dengan jelas mendorong pola yang seharusnya mengarah pada lebih sedikit sambungan antara klien dan server. Idenya adalah untuk menghindari chatty API's dengan panggilan seperti GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)mendukung metode yang lebih sedikit. Anda mungkin menerapkan hal yang sama di tumpukan layanan seperti ini:
[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();
}
}
Manfaatnya, untuk mata saya, adalah bahwa alih-alih memiliki logika bisnis Anda tersebar di atas banyak dan banyak metode yang terpisah GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), itu semua di satu tempat. Ini harus mengarah pada kode yang lebih mudah dikelola.
Secara kebetulan, Stack Exchange menyewa penulis Service Stack asli . Dia terus berkomitmen secara aktif untuk proyek Service Stack.
Saya sangat menyukai antrian pesan untuk hal-hal tertentu - dan walaupun WCF mengizinkannya, WebAPI tidak. ServiceStack memungkinkan layanan web yang sama dipanggil melalui MQ. Untuk info lebih lanjut tentang ini, lihat Redis MQ Host di: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@ tzerb telah menjawabnya dengan benar IMO tetapi saya ingin memperluas jawaban itu. ASP.NET Web API yang saat ini dalam tahap beta dan proyek OSS adalah kerangka kerja terdekat yang Anda cari.
Deskripsi singkat produk adalah sebagai berikut (dikutip dari halaman ASP.NET Web API ):
ASP.NET Web API adalah kerangka kerja yang membuatnya mudah untuk membangun layanan HTTP yang menjangkau berbagai klien, termasuk browser dan perangkat seluler. ASP.NET Web API adalah platform yang ideal untuk membangun aplikasi RESTful di .NET Framework.
Adapun aplikasi klien yang mungkin Anda gunakan untuk mengkonsumsi API web Anda, itu tentu tidak harus menjadi aplikasi ASP.NET. Anda dapat menggunakan API Anda dengan halaman HTML statis dengan menggunakan JavaScript. Anda mungkin menyelesaikan ini dengan mudah dengan beberapa perpustakaan JavaScript yang bermanfaat seperti jQuery.
Di sisi lain, Anda tentu dapat mengkonsumsi API Anda di situs server dalam aplikasi ASP.NET apa pun. Proyek Web API juga memperkenalkan HTTP .NET klien API baru bernama HttpClient yang membuatnya mudah untuk mengkonsumsi layanan HTTP.
Secara umum, berikut ini adalah sumber daya yang bagus untuk Anda mulai:
Memulai Dengan ASP.NET Web API - Tutorial, Video, Sampel
Ingatlah bahwa proyek ini masih dalam tahap beta. Saya sarankan Anda untuk mengikuti blog Henrik F Nielsen di mana ia memposting informasi tentang proyek terbaru yang belum dirilis. Anda dapat menjangkau kode sumber proyek dan alur pengembangan di dalam proyek ASP.NET Web Stack .
Saya pikir pedoman saat ini adalah menggunakan API Web MVC daripada WCF untuk REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
Model pengembangannya cukup dekat dan Anda melewati konfigurasi WCF yang terkadang tidak menyenangkan.