เท่าที่เขียนหนึ่งแอปพลิเคชั่นที่ใช้ประโยชน์ทั้ง ASP.NET/MVC และ WCF มันไม่ยอดเยี่ยม WebAPI อาจมีการปรับปรุงเรื่องต่าง ๆ แต่ในโครงการหนึ่งที่ฉันคุ้นเคยกับที่ใช้ WCF และ MVC ในแอพเดียวกันพวกเขาลงเอยด้วยการบำรุงรักษาแบบจำลองที่แตกต่างกันสองชุดเพื่อแสดงแนวคิดเดียวกัน - หนึ่งสำหรับรหัส WCF และอีกหนึ่งสำหรับ MVC รหัส. คุณสามารถจินตนาการผู้ทำแผนที่ทั้งหมดที่พวกเขาต้องเขียนเพื่อแปลสิ่งต่าง ๆ ระหว่างสองรุ่น - มีบรรทัดของโค้ดจำนวนมากที่สามารถ / ควรหลีกเลี่ยง
สาเหตุส่วนหนึ่งที่ทำให้เกิดเหตุการณ์นี้คือวัตถุที่ร้องขอและตอบสนองของ WCF ควรมีคำอธิบายประกอบด้วย [DataContract] และคุณสมบัติของ [DataMember] ในขณะที่ MVC ไม่ต้องการสิ่งนี้ Idiomatic MVC นั้นต้องการ ViewModels ซึ่งมีเป้าหมายแตกต่างจาก WCF DataContracts แน่นอนว่ามีความเป็นไปได้ที่การใช้ชุดโดเมนสองชุดเต็มรูปแบบนั้นเกี่ยวข้องกับกฎหมายของ Conwayมากกว่า WCF & MVC ที่ขัดแย้งกัน แต่ก็คุ้มค่าที่ชี้ให้เห็นว่า WCF และ MVC มีเป้าหมายและข้อกำหนดที่แตกต่างกันออกไป
โดยส่วนตัวฉันเป็นส่วนหนึ่งของการพัฒนาบริการที่เน้นความเรียบง่าย แต่ทรงประสิทธิภาพโดยเฉพาะเมื่อคุณต้องการลูกค้าหลาย ๆ คน ฉันคิดว่าการมาถึงของ JavaScript MVVM ที่ยอดเยี่ยมและ micro-MVC frameworks เป็นทางเลือกที่เป็นธรรมชาติเนื่องจากการเขียนโค้ดแอปพลิเคชันโดยใช้BackboneJS , KnockoutJSและอื่น ๆ ทำให้มีสภาพแวดล้อมการพัฒนาที่มีความสามารถ จากนั้นคุณสามารถใช้ส่วนหลังในไมโคร MVC ที่คุณเลือกเพื่อสร้างแอปพลิเคชันเว็บของคุณหรือบนไคลเอนต์มือถือและคู่ค้าของคุณอาจใช้ API เดียวกันจากระยะไกลเช่นกัน
ข้อเสนอแนะ
WebAPI หรือService Stackอาจเป็นตัวเลือกที่ดีสำหรับการสร้าง back end API ของคุณ ฉันแนะนำ Service Stack เนื่องจากฉันใช้งานมาหลายเดือนแล้วและพบว่ามันเป็นการทดแทนที่ยอดเยี่ยมสำหรับ WCF ฉันกำลังเขียนชุดกวดวิชาในกองบริการบนของบล็อก
กลุ่มการบำรุงรักษาบริการสแต็กได้โพสต์แอปพลิเคชันตัวอย่างโดยใช้กรอบการพัฒนา StackOverflow เช่นโคลนซึ่งแสดงรูปแบบการพัฒนาที่ฉันเชื่อว่าน่าสนใจเป็นพิเศษ มันเกี่ยวข้องกับบริการที่ใช้แบบจำลองที่เรียบง่ายซึ่งคุณสามารถจินตนาการได้ว่าเว็บไซต์ MVC แอพมือถือหรือสิ่งอื่น ๆ สามารถใช้งานได้อย่างง่ายดาย เป้าหมายการออกแบบของ ServiceStack สนับสนุนรูปแบบที่ชัดเจนซึ่งจะนำไปสู่การมีเพศสัมพันธ์น้อยลงระหว่างไคลเอนต์และเซิร์ฟเวอร์ แนวคิดก็คือเพื่อหลีกเลี่ยงการแชทของ API ด้วยการโทรชอบGetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)
วิธีการที่น้อยลง คุณอาจใช้สิ่งเดียวกันใน service stack ดังนี้:
[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();
}
}
ผลประโยชน์ให้กับดวงตาของฉันคือแทนที่จะมีการแพร่กระจายของตรรกะทางธุรกิจออกไปจำนวนมากและจำนวนของวิธีการที่แยกต่างหากGetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)
, GetCustomersInRegion(int regionId)
, GetCustomersWithSearchTerm(string searchTerm)
, GetCustomers()
มันคือทั้งหมดในที่เดียว สิ่งนี้จะนำไปสู่รหัสที่สามารถบำรุงรักษาได้มากขึ้น
บังเอิญกองแลกเปลี่ยนจ้างบริการกองเดิมผู้เขียน เขายังคงมุ่งมั่นอย่างแข็งขันต่อโครงการ Service Stack
ฉันชอบคิวข้อความอย่างยิ่งโดยเฉพาะในขณะที่ WCF อนุญาตให้ทำเช่นนี้ WebAPI ไม่ได้ ServiceStack ไม่อนุญาตให้เรียกใช้บริการเว็บเดียวกันผ่าน MQ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้โปรดดูที่ Redis MQ Host ที่: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis