ฉันจะจัดการการอภิปรายทางเทคนิคเกี่ยวกับ WCF กับ Web API ได้อย่างไร

ตอนนี้ฉันกำลังจัดการทีมงานของนักพัฒนาประมาณ 15 คนและเราติดอยู่ที่จุดหนึ่งในการเลือกเทคโนโลยีซึ่งทีมถูกแบ่งออกเป็นสองทีมตรงข้ามกันโดยสิ้นเชิงโต้วาทีการใช้ WCF กับเว็บ API

ทีม A ที่รองรับการใช้งาน Web API นำมาซึ่งเหตุผลเหล่านี้:

1. Web API เป็นวิธีการบริการการเขียนที่ทันสมัย ​​( Wikipedia )
2. WCF เป็นโอเวอร์เฮดสำหรับ HTTP มันเป็นทางออกสำหรับ TCP และ Net Pipes และโปรโตคอลอื่น ๆ
3. รุ่น WCF ไม่ใช่ POCO เนื่องจาก [DataContract] & [DataMember] และแอตทริบิวต์เหล่านั้น
4. SOAP ไม่สามารถอ่านได้และมีประโยชน์เท่ากับ JSON
5. SOAP เป็นค่าใช้จ่ายสำหรับเครือข่ายเมื่อเทียบกับ JSON (การส่งผ่าน HTTP)
6. ไม่มีวิธีการมากไป

ทีม B ที่รองรับการใช้ WCF พูดว่า:

1. WCF รองรับหลายโปรโตคอล (ผ่านการกำหนดค่า)
2. WCF รองรับการทำธุรกรรมแบบกระจาย
3. มีตัวอย่างที่ดีและเรื่องราวความสำเร็จมากมายสำหรับ WCF (ในขณะที่ Web API ยังเด็กอยู่)
4. ดูเพล็กซ์ยอดเยี่ยมสำหรับการสื่อสารสองทาง

การอภิปรายนี้ยังดำเนินต่อไปและฉันไม่รู้จะทำอย่างไร โดยส่วนตัวแล้วฉันคิดว่าเราควรใช้เครื่องมือเฉพาะสำหรับการใช้งานที่ถูกต้องเท่านั้น กล่าวอีกนัยหนึ่งเราควรใช้ Web API ถ้าเราต้องการให้บริการผ่าน HTTP แต่ใช้ WCF เมื่อพูดถึง TCP และ Duplex

การค้นหาทางอินเทอร์เน็ตทำให้เราไม่สามารถบรรลุผลที่มั่นคง มีบทความจำนวนมากที่ให้การสนับสนุน WCF แต่ในทางกลับกันเราก็พบว่ามีคนร้องเรียนเกี่ยวกับเรื่องนี้ ฉันรู้ว่าธรรมชาติของคำถามนี้อาจฟังดูโต้แย้ง แต่เราต้องการคำแนะนำที่ดีในการตัดสินใจ เราติดอยู่ในจุดที่การเลือกเทคโนโลยีโดยบังเอิญอาจทำให้เราเสียใจในภายหลัง เราต้องการเลือกด้วยดวงตาที่เปิดกว้าง

การใช้งานของเราส่วนใหญ่จะเป็นเว็บและเราจะเปิดเผยบริการของเราผ่าน HTTP ในบางกรณี (พูด 5 ถึง 10 เปอร์เซ็นต์) เราอาจต้องทำธุรกรรมแบบกระจาย

สิ่งที่ฉันควรทำตอนนี้? ฉันจะจัดการการอภิปรายนี้อย่างสร้างสรรค์ได้อย่างไร

เมื่อทั้งสองฝ่ายมีข้อโต้แย้งที่ดีและความคิดเห็นเกี่ยวกับปัญหานั้นรุนแรงเกินกว่าที่จะทำฉันทามติคุณในฐานะผู้จัดการต้องตัดสินใจและยุติการอภิปราย มิฉะนั้นมันจะเปลี่ยนเป็นวงกลมและเสริมตำแหน่งของผู้เข้าร่วมทั้งหมดให้มากขึ้น ยิ่งคุณรอนานเท่าไรการที่ฝ่ายพ่ายแพ้จะยิ่งยอมรับความพ่ายแพ้และทำงานได้อย่างมีประสิทธิผลมากขึ้น

เขียนข้อโต้แย้งทั้งหมดเห็นคุณค่าความสำคัญของโครงการแล้วตัดสินใจ เมื่อคุณทำไม่ได้ให้พลิกเหรียญ โครงการของคุณสามารถทำได้สำเร็จด้วยเทคโนโลยีอย่างใดอย่างหนึ่งและการเสียเวลาอันมีค่าด้วยการโต้วาทีที่ไม่จำเป็นจะต้องเสียค่าใช้จ่ายที่ไม่จำเป็น

สมมติว่าทั้งสองฝ่ายมีความถูกต้อง 100% ในทุกข้อโต้แย้งของพวกเขาซึ่งเป็นเรื่องสำคัญ?

รุ่น WCF ไม่ใช่ POCO เนื่องจาก [DataContract] & [DataMember] และแอตทริบิวต์เหล่านั้น

คุณสนใจไหม คุณวางแผนที่จะทำสิ่งที่ต้องใช้ POCO หรือไม่?

WCF รองรับการทำธุรกรรมแบบกระจาย

นี่คือสิ่งที่คุณจะใช้อีกครั้งและจำเป็นต้องสร้างหากคุณไม่มีเพราะคุณใช้เส้นทางอื่นหรือไม่

โดยทั่วไปจะไปถึงหัวใจของที่หนึ่ง:

• เสนอทุกสิ่งที่คุณต้องการ (หากไม่ได้เสนอทุกสิ่งที่คุณต้องการซึ่งทำให้คุณต้องทำงานน้อยที่สุด)
• เสนอขยะน้อยที่สุดที่คุณไม่ได้ใช้ แต่ต้องทนต่อไป

การโต้เถียงใด ๆ ที่ไม่ได้อยู่ในเส้นทางของสิ่งที่คุณต้องทำให้สำเร็จนั้นไม่เกี่ยวข้องและไม่ควรคำนึงถึงการตัดสินใจของคุณด้วยห้องเลื้อยในการพิจารณาการขยายตัวในอนาคต

ใส่สองเซ็นต์ของฉัน

ในฐานะที่เป็นผู้จัดการคุณควรถามเพื่อนร่วมทีมของคุณเพื่อเก็บไว้ในใจหลักการ YAGNI สิ่งนี้จะช่วยลดรายการสาเหตุที่นำมาใช้โดยทั้งสองทีม

การใช้งานของเราส่วนใหญ่จะเป็นเว็บและเราจะเปิดเผยบริการของเราผ่าน HTTP ในบางกรณี (พูด 5 ถึง 10 เปอร์เซ็นต์) เราอาจต้องทำธุรกรรมแบบกระจาย

แทนที่จะดำลงในธุรกรรมที่กระจายคุณควรพิจารณาทำงานกับค่าตอบแทนแทน

สิ่งสุดท้ายที่ต้องคำนึงถึงคือช่วงการเรียนรู้ คุณควรตัดสินใจได้ว่าจะเริ่มเรียนรู้เทคโนโลยีใหม่หรือไม่ขึ้นอยู่กับกำหนดเวลาสิ้นสุดโครงการของคุณในฐานะผู้จัดการ

หากคุณมีเวลาเหลือเฟือลองไปหาInnovation Dayสักหน่อยที่ Team A และ B จะมีวันหนึ่งในการพิสูจน์แนวคิดตามความต้องการเดียวกัน

โดยวิธีการกับคนที่บอกว่า " แบบจำลอง WCF ไม่ใช่ POCO เพราะ [DataContract] & [DataMember] และคุณลักษณะเหล่านั้น " บอกเขาว่า POCO นั้นเป็นสิ่งที่เป็นโดเมนทั่วไปและไม่ใช่วิธีที่ดีที่สุดในการเปิดเผย โดเมนของคุณคัดค้านลูกค้าทุกประเภทนี่คือสิ่งที่ DTO ใช้

สิ่งที่ฉันควรทำตอนนี้? ฉันจะจัดการการอภิปรายนี้อย่างสร้างสรรค์ได้อย่างไร

ก่อนอื่นจงหลีกเลี่ยงการกระทำ ในข้อโต้แย้งของทีม WebAPI ของคุณฉันพบว่า"Web API เป็นวิธีที่ทันสมัย" *, "WCF ไม่ใช่ POCO เนื่องจากคุณลักษณะเหล่านั้น"และ"SOAP นั้นไม่สามารถอ่านได้และมีประโยชน์เหมือนกับ JSON"หากไม่ผิดธรรมดา และจะไม่ช่วยในการตัดสินใจ

ดังนั้นสิ่งที่ต้องทำ: ตัดสินใจว่าคุณต้องการทำอะไรกับบริการของคุณจากนั้นเลือกเทคนิคที่เหมาะสมกับเป้าหมายนั้นรวมถึงการบำรุงรักษาและการขยายด้วยความเจ็บปวดน้อยที่สุด คุณสามารถทำสิ่งนี้ได้โดยเพียงแค่ทำการวิจัยว่ากรอบใด ๆ ที่กำหนดนั้นได้รับการสนับสนุนโดยกรอบงานที่จะใช้

วัสดุการอ่านที่น่าสนใจ:

• Mvc 4 vs. Wcf Web Api
• WCF หรือ ASP.NET Web APIs? สองเซ็นต์ของฉันในเรื่อง
• WebAPI หรือ WCF หรือไม่

* หมายเหตุ: คุณอ้างถึงวิกิพีเดียนี้ที่อ้างอิงคือ: " Web 2.0 การใช้งานเว็บได้ย้ายออกไปจากสถาปัตยกรรมเชิงบริการ (SOA) ด้วยสบู่ที่ใช้บริการเว็บต่อคอลเลกชันเหนียวมากขึ้นของทรัพยากรเว็บสงบ" นี่คือตัวอย่างของการใช้งานเมื่อต้องให้บริการของคุณจากเว็บเพจ สิ่งนี้สามารถทำได้อย่างง่ายดายด้วย WCF โดยใช้ WebHttpBinding มันไม่ได้บอกว่า"ใช้ WebAPI สำหรับเรื่องนี้"

หากคำถามนี้มีความยาวเกินกว่า"วิธีการจัดการการสนทนา" : ฉันจะใช้ WCF หากไม่ใช่บริการลูกค้าที่จะใช้บริการเพราะเมตาดาต้าของมันช่วยให้การสร้างไคลเอนต์ที่พิมพ์ได้ง่ายอย่างน่าอัศจรรย์อย่างน่าอัศจรรย์

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

การใช้งานของเราส่วนใหญ่จะเป็นเว็บและเราจะเปิดเผยบริการของเราผ่าน HTTP ในบางกรณี (พูด 5 ถึง 10 เปอร์เซ็นต์) เราอาจต้องทำธุรกรรมแบบกระจาย

จากนั้นคุณเขียนบริการเว็บ 5 ~ 10% ใน WCF หากบริการดังกล่าวมีการอ้างอิงภายในโครงการอื่น ๆ ก็ไม่มีข้อโต้แย้งใด ๆ ข้อดีของความสามารถในการนำเข้าสัญญา WCF เพื่อสร้างไคลเอ็นต์พร็อกซีไม่เปิดสำหรับการสนทนา ใช้การบูรณาการทั้งหมดประสิทธิภาพและความปลอดภัยของการพิมพ์ในระดับใหม่ทั้งหมด

คุณเขียนสิ่งที่จะใช้สำหรับการร้องขอ API สาธารณะ (อาจ) / Ajax ใน Asp.net เว็บ API

หากเป็นเพียงการโทร ajax เฉพาะหน้าคุณสามารถใช้ Asp.Net MVC

อย่าเลือกกอดพวกเขาทั้งหมด WCF และ Asp.net เว็บ API ให้บริการตามวัตถุประสงค์ที่แตกต่างกัน ไม่มีใครบอกว่าคุณไม่สามารถมีแอปเปิ้ลและส้มทั้งคู่ในสลัดผลไม้ของคุณ การพยายามเลือกสิ่งใดสิ่งหนึ่งและผลักมันลงมาทุก ๆ ฉากเป็นเพียงความเกียจคร้านที่แท้จริง

ทีมของเรามีการอภิปรายคล้ายกันเมื่อสองสามเดือนก่อน ปัจจัยในการตัดสินใจสำหรับเรานั้นมาจากวิธีที่เราจะสร้างและใช้งานเทคโนโลยีแต่ละอย่าง เนื่องจากเรากำลังสร้างแอปพลิเคชัน MVC อยู่แล้วและกำลังใช้ Knockout.js สำหรับการเชื่อมโยงข้อมูลเราจึงใช้ MVVM อย่างมีประสิทธิภาพด้วยคอนโทรลเลอร์เพียงแค่เป็น API สำหรับข้อมูล

สิ่งนี้ทำให้เราสามารถจำแนกการใช้เทคโนโลยีของเรากับโครงการนี้ได้ดังนี้:

• Web API จะใช้เป็น API ของเราสำหรับการโทรที่น่าพิศวงและ Ajax ทำให้พวกเขาเป็นคำสั่งของเราสำหรับรูปแบบ MVVM ตรรกะทางธุรกิจของเราสำหรับเว็บแอปพลิเคชันนั้นอยู่เบื้องหลังเลเยอร์นี้ผ่านคลาสและที่เก็บและโรงงานจำนวนมาก
• จากนั้น WCF จะถูกใช้เพื่อการจัดเก็บข้อมูลของเราเปิดเผยข้อมูลจากฐานข้อมูลของเราไม่เพียง แต่เว็บไซต์นี้บิตยังสำหรับเว็บไซต์หรือบริการอื่น ๆ ที่ใช้ข้อมูลที่เปิดเผย

แม้ว่านี่อาจไม่ใช่การตอบสนองทางเทคนิคที่ได้รับความนิยมหรือไฮเปอร์ แต่การพิจารณาว่าคุณต้องการอะไรก่อนและอย่างไรหรือเทคโนโลยีจะช่วยได้อย่างไรคือสิ่งที่ช่วยให้ทีมของฉันตัดสินใจว่าจะใช้เทคโนโลยีใด

กล่าวอีกนัยหนึ่งเราควรใช้ Web API ถ้าเราต้องการให้บริการผ่าน HTTP แต่ควรใช้ WCF เมื่อมาถึง TCP และ Duplex

นั่นจะเป็นวิธีการที่เหมาะสมที่สุด เป็นเรื่องธรรมดาที่จะมีทั้งบริการ WCF และ WebApi ในเว็บแอปพลิเคชันเดียวกันซึ่งทั้งสองมีวัตถุประสงค์ที่แตกต่างกัน

เพียงเพื่อแก้ไขข้อโต้แย้งเล็กน้อย:

รุ่น WCF ไม่ใช่ POCO เนื่องจาก [DataContract] & [DataMember] และแอตทริบิวต์เหล่านั้น

ในหลายกรณี WCF รุ่นทำงานโดยไม่มีแอตทริบิวต์ datacontract / datamember

SOAP ไม่สามารถอ่านได้และมีประโยชน์เท่ากับ JSON

มันไม่เป็นความจริง แต่เว็บเซอร์วิสของ WCF มักจะมี XML ธรรมดามากกว่า SOAP ที่ป่อง นี้แน่นอนคือสามารถอ่านได้

อาร์กิวเมนต์หนึ่งสำหรับ WCF: หากมี WSDL ให้บริการมีเครื่องมือมากมายในเทคโนโลยีเกือบทั้งหมดที่สามารถสร้างพรอกซีจากเมตาดาต้าได้ ในทางกลับกัน JSON Schema ยังไม่ได้รับการสนับสนุนอย่างกว้างขวางทั้งหมด

ทำไมไม่ลองใช้บริการของ WCF Data? ข้อความค้นหาสไตล์ OData / webapi ที่ดีและการใช้งานด้วยพลังของ WCF และความสามารถในการส่งคืนได้JSONดี นอกจากนี้ Wcf ก็ไม่ได้เลวร้ายถ้าคุณมีรหัสโฮสติ้ง wcf อัตโนมัติที่ดีดังต่อไปนี้:

https://github.com/ImaginaryDevelopment/MvcOdata

ฉันจะบอกว่าพวกเขาไม่ได้อยู่ห่างไกลกันเลยยกเว้นว่าเมื่อเราไปใช้WebApiกับส่วนหน้าและWCF data servicesระดับกลางคนที่WebApiขว้างปาใส่สิ่งง่าย ๆ เช่นสตริงที่มีหรือตัวดำเนินการจับคู่สตริง

สถาปนิกที่ดีชะลอการตัดสินใจทางเทคโนโลยีจนกว่าจะจำเป็นจริงๆ

ในคำอื่น ๆ อย่าตัดสินใจจนกว่าลูกค้าจะต้องเชื่อมต่อจริง คุณสามารถสร้างเลเยอร์บริการที่ทดสอบอย่างสมบูรณ์โดยไม่ต้องใส่กลไกการขนส่ง / การส่งมอบ 95% + ของงานที่สามารถทำได้ "ใต้" อะแดปเตอร์นอกกรอบ

มาถึงเวลาที่จะเปิดเผยบริการเหล่านั้นไปยังไคลเอนต์ระยะไกลคุณสามารถเลือกกรอบการทำงานที่ทันสมัยที่สุดจากชั้นวางและเขียนโปรแกรมเสริมบาง ๆ ผ่านเลเยอร์บริการที่หลากหลาย

นรกถ้าชั้นบริการ "ของจริง" ของคุณทำได้ดีแล้วคุณสามารถลองห่อหลาย ๆ อันด้วยค่าใช้จ่ายเพียงเล็กน้อย

นั่นเป็นคำตอบที่ไม่เชื่อฟัง ในทางปฏิบัติคุณอาจต้องการที่จะเลือกที่ง่ายเครื่องมือปิดการเก็บรักษาเพื่อความสะดวกในการทดสอบการรวมในช่วงต้นและบ่อย - แต่ยังคง จำกัด การพึ่งพาอาศัยกันของคุณเกี่ยวกับมันและรักษามันอย่างเคร่งครัดเป็นเพียงชั้นการสื่อสารบางกว่าจริงบริการ

หากคุณใช้วิธีการนี้คุณอาจพบว่าคุณเลือกเครื่องมือที่ง่ายที่สุดในการใช้งานในตอนแรกและไม่มีใครจะยุ่งยากเพราะทีมรู้ว่าพวกเขาสามารถใช้เครื่องมือหรือกรอบที่ซับซ้อนกว่าหรือทันสมัยกว่าในภายหลังหากจำเป็นด้วยความพยายามน้อยที่สุด

ดังนั้นฉันหันหน้าไปทางเลือกที่เดียวกันตอนนี้ผมถามตัวเองว่าสิ่งที่เป็นส่วนย่อยของคุณสมบัติจาก WCF ทีมงานของเราจะใช้ในขณะนี้ เราใช้โปรโตคอลที่แตกต่างกันหรือไม่? ไม่เราใช้การสนับสนุนธุรกรรมหรือไม่ ไม่ (แม้ว่าเราจะใช้กลไกความสอดคล้องในที่สุดเอง) เราใช้ดูเพล็กซ์หรือไม่? เลขที่

ทำไมเราถึงต้องการใช้ Web API การรวมส่วนหน้าได้ง่ายขึ้น (ลบชั้นบริการเพิ่มเติมที่มีอยู่ในตอนนี้), SignalR สำหรับการตอบกลับไปยังไคลเอนต์, การแคชสำหรับ GET

อาจเป็นเหตุผลหนึ่งที่สามารถหาเหตุผลอื่น ๆ ได้ :) เช่นกันเหตุผลที่จะอยู่กับ WCF

ถ้าฉันอยู่ในตำแหน่งของคุณฉันจะเริ่มต้นด้วยการตรวจสอบความสามารถของทีมของคุณ หากทุกคนในทีมของคุณรู้จัก WCF อยู่แล้วและมีเพียงไม่กี่เปอร์เซ็นต์เท่านั้นที่รู้จัก Web API ดังนั้นการตัดสินใจของคุณก็มีไว้สำหรับคุณแล้ว

โดยทั้งหมดถ้าคุณมีเวลาแล้วก็ลงทุนในการเรียนรู้และพัฒนาฐานความรู้ของคุณ แต่ไม่ต้องเสียค่าใช้จ่ายตามความต้องการทางธุรกิจและประสิทธิผลของ บริษัท

ฉันจะถามว่าคุณต้องการสนับสนุนรูปแบบการโต้ตอบแบบใด อินเทอร์เฟซภายนอกที่คุณต้องการมีลักษณะคล้าย RPC หรือ REST มากขึ้นหรือไม่ จากประสบการณ์ของฉันมักจะอยู่ระหว่าง แต่ส่วนใหญ่อย่างใดอย่างหนึ่ง

คุณใช้บริการของคุณเองสำหรับโครงการอื่น ๆ ใน. Net หรือไม่ นี่อาจเป็นคำถามเดียวที่เปิดเผยมากที่สุดที่คุณสามารถถามได้ WCF มีข้อได้เปรียบในการทำให้อินเทอร์เฟซของคุณเป็นนามธรรมในไลบรารีคลาสแยกต่างหากและสามารถสร้างและฉีดไคลเอ็นต์ของคุณ ในฐานะที่เป็นส่วนขยายของสิ่งนี้คุณสามารถติดตั้งโครงการ WCF ของคุณด้วยจุดสิ้นสุด JSON และ SOAP / WSDL ฉันได้ทำไปแล้ว WCF ยังมีการรับประกันที่ดีกว่ากับส่วนต่อประสานที่คุณกำหนด

ที่กล่าวว่าหากคุณคาดว่าจะมีลูกค้าจาก XML แพลตฟอร์มอื่นโดยทั่วไป SOAP เพียงอย่างเดียวจะมีค่าใช้จ่ายที่สามารถวัดได้เกินกว่าจุดสิ้นสุด JSON ธรรมดา ๆ หากคุณไปเส้นทาง JSON / Web API คุณจะต้องดีขึ้นมากในการทำเอกสารเกี่ยวกับวิธีโต้ตอบกับ endpoints และ API ของคุณ

โดยทั่วไปฉันขอแนะนำให้เขียนเอกสาร API แบบง่ายซึ่งระบุวิธีที่คุณจะส่งข้อมูลและวิธีที่คุณต้องการการตอบสนองสำหรับโครงสร้างวัตถุคำขอเดียว เขียนกรณีทดสอบของคุณด้วยวิธีที่เป็นสากลมากที่สุดและจัดทำเป็นเอกสารดังกล่าว ฉันอยากจะแนะนำคำสั่งที่เรียบง่าย จากนั้นให้สมาชิกหลายคนของคุณใช้สิ่งนี้โดยใช้ WCF และกับ Web API จากนั้นดูว่าใครชนะ

โดยส่วนตัวแม้ว่าจะมีโครงการขนาดใหญ่และการติดตั้งใช้งานกับ WCF แต่ฉันก็เชื่อมั่นในการใช้งานที่ง่ายที่สุดซึ่งในความคิดของฉันตรงไปตรงมากับการใช้ผล JSON และพฤติกรรมการแทนที่ใน Global.asax.cs หากเอกสารประกอบของ API มีคำสั่ง curl และคุณสามารถใช้ฟังก์ชันการทำงานทั้งหมดของ API ของคุณด้วยตัวอย่าง curl มันจะกลายเป็นเรื่องง่ายสำหรับลูกค้าที่จะใช้งานในภาษาใด ๆ ที่สนับสนุนเว็บอินเตอร์เฟส นี่คือที่ที่ WCF เริ่มล้มลง การมี API ที่กำหนดไว้อย่างดีพร้อมเอกสารที่ไม่เชื่อเรื่องพระเจ้านั้นดีกว่าการมีโครงสร้างด้วยเครื่องมืออัตโนมัติเมื่อจัดการกับระบบต่างประเทศ การพูดในฐานะผู้บริโภคของระบบเหล่านั้นจากแพลตฟอร์มอื่น ๆ

สิ่งหนึ่งที่นอกเหนือจากนั้นก็คือการใช้งานลูกค้าของคุณในสองภาษาที่แตกต่างกัน ทำไคลเอนต์ใน C # แต่ยังทำใน Node.js หรือ Python และดูว่าพวกเขาเข้ากันได้ดีแค่ไหน การออกกำลังกายเพียงอย่างเดียวนั้นจะช่วยให้คุณสลัดจุดจบใน API ของคุณ