WCF / SOA - ทำไมฉันควรสร้างวัตถุพารามิเตอร์สำหรับคำของ่าย ๆ

บริษัท ของเรากำลังเริ่มต้นการริเริ่ม SOA ที่ค่อนข้างใหญ่ เรากำลังทำสิ่งต่าง ๆ มากมายถูกต้อง: มีการสื่อสารที่ดี เงินสำหรับเครื่องมือตามความเหมาะสม และเราได้นำความเชี่ยวชาญที่ดีบางอย่างมาช่วยเราในการเปลี่ยนแปลง

เรากำลังพยายามพัฒนามาตรฐานที่เราสามารถปฏิบัติตามเป็นกลุ่มและหนึ่งในมาตรฐานที่เสนอนั้นรบกวนฉันไม่น้อย:

เรามีมาตรฐานในรูปแบบที่ทุกการดำเนินการใช้วัตถุคำขอและส่งกลับวัตถุตอบสนอง

ฉันรู้ว่านี่เป็นวิธีมาตรฐานมากกว่าหรือน้อยกว่าสำหรับคนจำนวนมาก แต่ฉันถามว่าทำไมฉันถึงต้องรำคาญ (ฉันไม่ค่อยดีเท่าไหร่ที่มีปัญญาที่ได้รับฉันต้องการบางอย่าง)

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

ความไม่สงบของฉันได้รับการขยายโดยดูที่ WSDL ที่สร้างขึ้นจากสัญญาของเรา WCF สร้างคำขอและข้อความตอบกลับโดยอัตโนมัติและตัดคำแม้แต่วัตถุคำขอ / ตอบกลับ

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

คำถามของฉันคือเหตุผลที่ฉันควรห่อคำขอและคำตอบโดยอัตโนมัติเมื่อ:

• มันทำให้การบริการที่เรียบง่ายแสดงออกน้อยลง
• คุณจะทำมันต่อไปสำหรับบริการที่ซับซ้อน
• WCF สร้างข้อความร้องขอ / ตอบกลับ

ฉันได้พบข้อโต้แย้งต่อไปนี้ในความโปรดปรานของวิธีการนี้:

สนับสนุนการกำหนดเวอร์ชันโดยอนุญาตให้พารามิเตอร์ทางเลือกเลื่อนลงในวัตถุคำขอ

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

จะช่วยให้ข้อมูลทั่วไปและพฤติกรรมที่จะแยกไปที่ชั้นฐาน

อันนี้มีน้ำหนักกับฉัน

มันพาคนออกจากพฤติกรรมสไตล์ RPC และต่อพฤติกรรมการส่งข้อความ

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

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

ฉันคิดว่าการกำหนดเวอร์ชันอาจเป็นอาร์กิวเมนต์ที่ดีที่สุด เมื่อคุณมีสัญญาการดำเนินงานที่มีอยู่เช่น

int GetPersons(int countryId);

ที่คุณต้องการปรับปรุงเช่นโดยตัวกรองอื่นในภายหลัง

int GetPersons(int countryId, int age);

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

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

อย่างไรก็ตามฉันก็อยากจะตั้งชื่อวัตถุของคุณอย่างเหมาะสม แม้ว่ามันจะเป็นการห่อหุ้ม int แต่ถ้าคุณเริ่มต้นด้วยIntMessageหรือสิ่งที่คล้ายกันคุณไม่ได้ทำสิ่งที่ชอบด้วยตัวคุณเอง คุณต้องตั้งชื่อมันเช่นPersonFilterตั้งแต่เริ่มต้นซึ่งหมายความว่าคุณต้องคิดเพียงเล็กน้อยเกี่ยวกับสิ่งที่การเรียกใช้บริการนี้ควรคาดหวังว่าเป็นพารามิเตอร์ทางความหมายและสิ่งที่ควรทำ อาจจะ (และเป็นสิ่งที่คลุมเครือมาก) ที่จะช่วยในการพัฒนาบริการที่เหมาะสมและรักษา API ที่มีขนาดเหมาะสม

จะช่วยให้ข้อมูลทั่วไปและพฤติกรรมที่จะแยกไปที่ชั้นฐาน

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

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

โดยรวมแล้วนอกเหนือจากเวอร์ชันแล้วฉันไม่สามารถหาเหตุผลนักฆ่าที่ทำแบบนั้นได้

ฉันคิดว่าMartin Fowler ในData Transfer Objectนั้นเหมาะสมแล้ว

เมื่อคุณทำงานกับอินเทอร์เฟซระยะไกลเช่น Remote Facade (388) การโทรแต่ละครั้งจะมีราคาแพง ดังนั้นคุณต้องลดจำนวนการโทรและนั่นหมายความว่าคุณต้องถ่ายโอนข้อมูลมากขึ้นด้วยการโทรแต่ละครั้ง วิธีหนึ่งในการทำเช่นนี้คือการใช้พารามิเตอร์จำนวนมาก อย่างไรก็ตามนี่เป็นเรื่องที่น่าอึดอัดใจในการเขียนโปรแกรม - จริง ๆ แล้วมันเป็นไปไม่ได้สำหรับภาษาเช่น Java ที่คืนค่าเพียงค่าเดียว

ทางออกคือการสร้าง Data Transfer Object ที่สามารถเก็บข้อมูลทั้งหมดสำหรับการโทร มันจะต้องเป็นแบบอนุกรมเพื่อข้ามการเชื่อมต่อ โดยปกติแล้วแอสเซมเบลอร์จะใช้ในฝั่งเซิร์ฟเวอร์เพื่อถ่ายโอนข้อมูลระหว่าง DTO และวัตถุโดเมนใด ๆ

เช่นเดียวกันอาจนำไปใช้กับคำขอ สำหรับ RPC และทำไมมันไม่ดี:

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

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