การสร้างเลเยอร์บริการมีความสำคัญอย่างไร

ฉันเริ่มสร้างแอพใน 3 เลเยอร์ (DAL, BL, UI) [ส่วนใหญ่จัดการกับ CRM, รายงานการขายและสินค้าคงคลัง]

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

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

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

ฉันพยายาม google บนมัน แต่ฉันยังคงสับสนและไม่สามารถตัดสินใจได้ว่าจะทำอย่างไร

หนังสือของ Martin Fowler ระบุ "รูปแบบของสถาปัตยกรรมองค์กร":

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

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

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

ด้วย CRM การขายและสินค้าคงคลังจะมีกรณีการใช้งาน CRUD จำนวนมากซึ่งมักจะมีการติดต่อแบบตัวต่อตัวกับการดำเนินงานของเลเยอร์บริการเกือบทุกครั้ง การตอบสนองต่อการสร้างอัปเดตหรือลบวัตถุโดเมนควรมีการประสานงานและทำธุรกรรมแบบอะตอมโดย Service Layer

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

โดยสรุปเป็นเรื่องดีที่จะใช้ Service Layer - ยิ่งกว่านั้นฉันคิดว่าในตัวอย่างที่คุณให้มาเพราะดูเหมือนว่าคุณมีลูกค้าหลายรายที่มีตรรกะทางธุรกิจ

การเพิ่มเลเยอร์บริการเนื่องจากคุณได้ประเมินแนวคิดและสรุปแนวทางที่ดีที่สุด: ดี

การเพิ่มเลเยอร์บริการเพราะนั่นคือสิ่งที่เด็กเจ๋ง ๆ ทำ: เลวร้าย

หากลำไส้ของคุณบอกว่าคุณไม่ต้องการมันก็ไม่ควรทำ

หนึ่งในการพัฒนาที่น่าผิดหวังในโลกแห่งการเขียนโปรแกรมตลอด 10 ปีที่ผ่านมาคือมันกลายเป็น 'แฟชั่น' ที่น่ารำคาญโดยผู้คนติดตามแนวโน้มและ bandwagons ราวกับว่าพวกเขาเป็นรองเท้าของฤดูกาลนี้ อย่าตกหลุมพรางนั้น เพราะฤดูกาลหน้า 'ทุกคน' จะบอกคุณว่าคุณควรออกแบบมันด้วยวิธีอื่น

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

มีหลายปัจจัยที่เข้าสู่การตัดสินใจในการสร้างเลเยอร์บริการ ฉันได้สร้างเลเยอร์บริการในอดีตด้วยเหตุผลดังต่อไปนี้

1. รหัสที่ต้องใช้ซ้ำโดยไคลเอนต์หลายราย
2. ห้องสมุดบุคคลที่สามที่เรามีใบอนุญาต จำกัด สำหรับ
3. บุคคลที่สามที่ต้องการจุดบูรณาการเข้าสู่ระบบของเรา
4. การรวมศูนย์ตรรกะทางธุรกิจซ้ำซ้อน

กรณีที่ 1: คุณกำลังสร้างฟังก์ชั่นพื้นฐานที่จำเป็นต้องใช้กับไคลเอนต์ต่าง ๆ มากมาย Service layer สร้างขึ้นเพื่อการใช้งานสำหรับลูกค้าที่แตกต่างกัน

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

กรณีที่ 3: คุณกำลังสร้างฟังก์ชันการทำงานสำหรับบุคคลที่สามเพื่อสื่อสารกับคุณ ในตัวอย่างของคุณคุณสามารถตั้งค่าจุดสิ้นสุดสินค้าคงคลังเพื่ออนุญาตให้ผู้ขายส่งข้อความถึงคุณเกี่ยวกับการจัดส่งผลิตภัณฑ์ขาเข้า

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

ทั้งหมดนี้ถูกกล่าวว่ามีเชิงลบที่อาจเกิดขึ้นกับชั้นบริการ

1. เพิ่มความซับซ้อนของระบบ ซึ่งก่อนหน้านี้คุณมีเพียงแอปพลิเคชั่นเดียวที่จะแก้ไขข้อบกพร่องตอนนี้คุณมีสองใบ ปัญหาการผลิตจำเป็นต้องตรวจสอบการตั้งค่าแอพไคลเอนต์การตั้งค่าแอพบริการหรือปัญหาการสื่อสารระหว่างไคลเอ็นต์การตั้งค่าและแอพเซิร์ฟเวอร์อย่างถูกต้อง นี่อาจเป็นเรื่องยุ่งยากหากคุณไม่เคยทำมาก่อน
2. จุดหนึ่งของความล้มเหลว หากคุณมีบริการขัดข้องลูกค้าทั้งหมดจะได้รับผลกระทบ เมื่อรหัสไม่ถูกปรับใช้ในลักษณะนี้ความเสี่ยงอาจน้อยลง (แม้ว่าจะมีวิธีการลดขนาดนี้)
3. การกำหนดเวอร์ชันอาจทำได้ยากกว่า เมื่อคุณมีแอพหนึ่งตัวที่ใช้บริการที่ปรับใช้การเปลี่ยนแปลงอินเตอร์เฟสสามารถทำได้พร้อมกันระหว่างสองแอพ เมื่อคุณมีลูกค้าหลายรายตอนนี้คุณต้องจัดการว่าใครอยู่บน V1 ใครอยู่บน V2 และประสานงานการลบ V1 (เมื่อคุณรู้ว่าทุกคนอัปเดตเป็น V2)

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

เลเยอร์บริการส่วนใหญ่ที่ฉันเห็นเป็นเรื่องยุ่งเหยิง บริการมักจะมีวิธีการที่แตกต่างกันมาก 1,500 LOC ไม่ใช่เรื่องยาก วิธีการต่าง ๆ นั้นไม่มีอะไรเหมือนกัน แต่ใช้รหัสร่วมกัน ซึ่งจะส่งผลในระดับสูงมีเพศสัมพันธ์ต่ำการทำงานร่วมกัน นอกจากนี้ยังละเมิดOCPด้วยเนื่องจากทุกครั้งที่ต้องการการดำเนินการใหม่คุณต้องแก้ไขรหัสแทนที่จะขยายฐานรหัส เลเยอร์บริการที่สร้างขึ้นอย่างดีนั้นเป็นไปได้ในทางทฤษฎี แต่ฉันไม่เคยเห็นมันมาก่อนในทางปฏิบัติ

CQRSแก้ปัญหาเหล่านี้และป้องกันไม่ให้คุณต้องสร้างหนึ่งในเลเยอร์บริการขั้นตอนเหล่านั้น

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

ในองค์กรส่วนใหญ่ถ้าคุณไปสปอนเซอร์ทางธุรกิจของคุณและถามพวกเขาว่า "คุณต้องการให้แผนกอื่น ๆ ได้รับประโยชน์จากระบบนี้ที่เรากำลังพัฒนาด้วยงบประมาณของคุณหรือไม่" พวกเขาจะหัวเราะเยาะคุณ ทำให้มันทำงานให้กับสปอนเซอร์ธุรกิจของคุณก่อนจากนั้นเริ่ม twiddling ด้วยการนำรหัสนั้นกลับมาใช้ใหม่ (ตามเวลาของแผนกของคุณ)

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

ป.ล. ถ้าคุณกำลังทำงานใน Java, Joshua Bloch มีคำแนะนำเกี่ยวกับอินเทอร์เฟซที่ยอดเยี่ยมมากมายตลอดทั้งเล่ม Effective Java ของเขา

ฉันเห็นด้วยกับคุณ. ไม่จำเป็นต้องรวมอีกหนึ่งเลเยอร์หากคุณใช้ UI เดียว

DAL, BL และ UI / Controller เป็นการผสมผสานที่ดีในการออกแบบแอปพลิเคชัน หากคุณวางแผนที่จะใช้ UI เดียวไม่จำเป็นต้องเตรียมเลเยอร์เพิ่มเติม การรวมเลเยอร์เพิ่มเติมลงในแอปพลิเคชันจะเพิ่มความพยายามในการพัฒนา / เวลาเท่านั้น

schenerio อื่นคือการใช้ UIs หลายรายการในแอปพลิเคชันของคุณมันเป็นการดีที่จะมีเลเยอร์บริการเพื่อจัดการกับ UIs ในกรณีนี้

Stack Overflow: การสนทนาเกี่ยวกับรูปแบบเลเยอร์บริการ

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