ASP.NET MVC กับ WCF สำหรับ REST API + การใช้เว็บเพจ


14

ฉันคิดว่าการสนทนาสำหรับการใช้บริการเชิงโปรแกรมเทียบกับการโต้ตอบกับมนุษย์นั้นชัดเจน

แต่ถ้าฉันต้องสร้างแอปพลิเคชั่นที่ใช้ทั้ง API เชิงโปรแกรมและเว็บไซต์ที่ใช้ประโยชน์จากข้อมูลที่เชื่อมต่อด้วย API เดียวกันมันจะให้ประโยชน์แก่ ASP.NET เพียงอย่างเดียวหรือไม่

การรวม ASP.NET และ WCF เข้ากับแอพพลิเคชันเดียวกันทำได้ง่ายเพียงใด?

คำตอบ:


11

เท่าที่เขียนหนึ่งแอปพลิเคชั่นที่ใช้ประโยชน์ทั้ง 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


หมายเหตุ: ServiceStack อนุญาตให้สามารถเรียกใช้บริการเว็บเดียวกันผ่าน MQ ได้ที่โฮสต์ Redis MQ ที่: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
mythz

ขอบคุณมาก @mythz! ฉันไม่รู้
Kyle Hodgson

แต่ดูเหมือนว่า mvc4 กำลังไปตามเส้นทางของเว็บ api ... มันไม่ได้ทำให้กรอบของ
Xster

หลังจากต่อสู้กับ "กรอบการสนับสนุนอย่างเป็นทางการ" (WCF pre WebAPI) ในช่วงสองปีที่ผ่านมานี่ไม่ได้เป็นส่วนหนึ่งของเกณฑ์การเลือกของฉันอีกต่อไป ไม่ได้บอกว่า WebAPI ดีหรือไม่ดีฉันยังไม่ได้ลองเลย ฉันไม่รู้สึกว่า ServiceStack กำลังแก้ไขปัญหาของฉัน
Kyle Hodgson

3
ระบุสิ่งที่ชัดเจนที่นี่ แต่ ViewModels และวัตถุตอบกลับจากบริการ WCF เป็น 2 สิ่งแยกกันอย่างสิ้นเชิง ViewModel อาจเป็นเพียงส่วนหนึ่งของข้อมูลหรือชิ้นส่วนของข้อมูลจากแหล่งต่าง ๆ รวมกัน การมีชุดของวัตถุที่แตกต่างกันสำหรับ ViewModels เป็นสิ่งที่จำเป็นสำหรับ MVC ซึ่งข้อมูลมาจาก (WCF หรืออย่างอื่น) ไม่สำคัญ นอกจากนี้ยังมี Automapper สำหรับการจับคู่ระหว่างชนิดของวัตถุเพื่อบันทึก X.Name = Y.Name รหัสแผ่นสำเร็จรูปทั้งหมด
ozz

4

@tzerbตอบถูกต้อง IMO แต่ฉันต้องการขยายคำตอบนั้น ASP.NET Web API ซึ่งขณะนี้อยู่ในช่วงเบต้าและโครงการ OSS เป็นกรอบงานที่ใกล้เคียงที่สุดที่คุณกำลังมองหา

คำอธิบายสั้น ๆ ของผลิตภัณฑ์มีดังนี้ (อ้างอิงจากเพจ ASP.NET Web API ):

ASP.NET Web API เป็นเฟรมเวิร์กที่ทำให้การสร้างบริการ HTTP ที่เข้าถึงลูกค้าได้หลากหลายรวมถึงเบราว์เซอร์และอุปกรณ์มือถือ ASP.NET Web API เป็นแพลตฟอร์มที่เหมาะสำหรับการสร้างแอปพลิเคชั่น RESTful ใน. NET Framework

สำหรับแอปพลิเคชันไคลเอนต์ที่คุณอาจใช้เพื่อใช้งานเว็บ API ของคุณแน่นอนว่ามันไม่จำเป็นต้องเป็นแอปพลิเคชัน ASP.NET คุณสามารถใช้ API ของคุณกับหน้า HTML คงที่โดยใช้ JavaScript คุณสามารถทำสิ่งนี้ได้อย่างง่ายดายด้วยไลบรารี JavaScript ที่มีประโยชน์เช่น jQuery

ในทางกลับกันคุณสามารถใช้ API ของคุณบนเว็บไซต์เซิร์ฟเวอร์ในแอปพลิเคชัน ASP.NET ใดก็ได้ โครงการ Web API ยังเปิดตัวไคลเอนต์ HTTP .NET API ใหม่ชื่อ HttpClient ซึ่งทำให้ง่ายต่อการใช้บริการ HTTP

โดยทั่วไปนี่เป็นชุดทรัพยากรที่ดีสำหรับคุณในการเริ่มต้น:

เริ่มต้นกับ ASP.NET Web API - บทแนะนำ, วิดีโอ, ตัวอย่าง

จำไว้ว่าโครงการยังอยู่ในช่วงเบต้า ฉันแนะนำให้คุณติดตามบล็อกHenrik F Nielsenที่ซึ่งเขาโพสต์ข้อมูลเกี่ยวกับการอัปเดตล่าสุดที่ยังไม่เผยแพร่ในโครงการ คุณสามารถเข้าถึงรหัสที่มาของโครงการและการไหลของการพัฒนาภายในโครงการเว็บ ASP.NET กอง


โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.