การนำ Design Logic ไปใช้

ปรัชญาแนวทางการดำเนินงาน

น้ำตก

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

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

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

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

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

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

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

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

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

การพัฒนาที่คล่องตัว

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

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

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

การพัฒนาที่เพิ่มขึ้น

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

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

การควบคุมการไหลของโปรแกรม

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

รหัสผู้จัดงาน

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

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

การสร้างโครงการ

ชั้น

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

เลเยอร์กับเลเยอร์

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

รูปที่ 8-1: องค์กรสามชั้นขั้นพื้นฐาน

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

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

ชั้นทางกายภาพ

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

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

การเพิ่มรูปแบบให้กับเลเยอร์

สามชั้นพื้นฐานให้ภาพรวมระดับสูง มาเพิ่มรูปแบบโครงสร้างเพื่อสร้างสถาปัตยกรรมองค์กรที่แข็งแกร่ง ผลลัพธ์แสดงในรูปที่ 8-2

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

กระแสการตัดสินใจ

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

มีสองวิธีในการจัดบริการของคุณ:

• มุ่งเน้นการกระทำ
• ขับเคลื่อนโดยรัฐ

แนวทางการดำเนินการ

ด้วยการจัดระเบียบบริการตามการกระทำของผู้ใช้ คุณกำลังใช้ตรรกะของแอปพลิเคชันโดยนำเสนอบริการ ซึ่งแต่ละบริการจะจัดการคำขอเฉพาะจากเลเยอร์การนำเสนอ สิ่งนี้เรียกอีกอย่างว่ารูปแบบสคริปต์ธุรกรรม วิธีนี้เป็นที่นิยมเพราะง่ายและดูเป็นธรรมชาติมาก ตัวอย่างของวิธีการที่ทำตามวิธีนี้ ได้แก่ BookStoreService.AddNewOrder(Order order) และ BookStoreService.CancelOrder(int orderId)

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

แนวทางการขับเคลื่อนของรัฐ

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

โครงการโครงสร้างข้อมูล

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

• บริการนำเสนอข้อมูล ข้อมูลเป็นภาพสะท้อนของฐานข้อมูลเชิงสัมพันธ์
• ข้อมูลต้องถูกแมปกับออบเจกต์และบริการให้การเข้าถึงออบเจกต์
• ข้อมูลที่นำเสนอโดยบริการจะต้องอิงตามสคีมา

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

การเลือกเครื่องมือจัดเก็บข้อมูล

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

• บันทึก
• ไฟล์ app.config
• ไฟล์ xml
• ไฟล์ข้อความล้วน
• ฐานข้อมูล
• การจัดคิวข้อความ

แต่ละร้านมีลักษณะเฉพาะของตัวเองและสามารถปรับแต่งตามความต้องการเฉพาะได้

การออกแบบการไหลของข้อมูล

การไหลของข้อมูลโดยใช้ ADO.NET

ด้วยการใช้บริการที่เน้นข้อมูลเป็นศูนย์กลางในเลเยอร์ตรรกะของแอปพลิเคชัน คุณจะออกแบบโฟลว์ข้อมูลของคุณโดยใช้ ADO.NET ไลบรารีคลาส .NET Framework มีอินเทอร์เฟซโปรแกรมประยุกต์ (API) ที่ครอบคลุมสำหรับการจัดการข้อมูลในโค้ดที่ได้รับการจัดการ เรียกว่า ADO.NET API สามารถพบได้ในเนมสเปซ System.Data การแยกผู้ให้บริการข้อมูลและที่เก็บข้อมูลอย่างสมบูรณ์เป็นคุณลักษณะการออกแบบที่สำคัญของ ADO.NET คลาสต่างๆ เช่น DataSet, DataTable และ DataRow ได้รับการออกแบบมาเพื่อจัดเก็บข้อมูล แต่ไม่รู้ว่าข้อมูลมาจากไหน ซึ่งถือว่าเป็นแหล่งข้อมูลที่ไม่เชื่อเรื่องพระเจ้า ชุดของคลาสที่แยกต่างหาก เช่น SqlConnection, SqlDataAdapter และ SqlCommand จะดูแลการเชื่อมต่อกับแหล่งข้อมูล ดึงข้อมูล และเติมชุดข้อมูล DataTable และ DataRow คลาสเหล่านี้อยู่ในเนมสเปซย่อย เช่น System.Data.Sql, System.Data.OleDB, System.Data.Oracle เป็นต้น ขึ้นอยู่กับแหล่งข้อมูลที่คุณต้องการเชื่อมต่อ คุณสามารถใช้คลาสในเนมสเปซที่ถูกต้อง และขึ้นอยู่กับขอบเขตของผลิตภัณฑ์ที่คุณใช้ คุณจะพบว่าคลาสเหล่านี้มีฟังก์ชันมากหรือน้อย

เนื่องจากชุดข้อมูลไม่ได้เชื่อมต่อกับแหล่งข้อมูล จึงสามารถใช้ในการจัดการการไหลของข้อมูลในแอปพลิเคชันได้ค่อนข้างสำเร็จ รูปที่ 8-5 แสดงการไหลของข้อมูลเมื่อทำเช่นนี้

ลองดูที่โครงการนี้และจินตนาการว่ามีคนเข้าสู่ระบบร้านหนังสือของคุณและสั่งซื้อหนังสือสามเล่ม เลเยอร์การนำเสนอจัดการสถานะของตะกร้าสินค้า ลูกค้าพร้อมที่จะทำการสั่งซื้อและได้ให้ข้อมูลที่จำเป็นทั้งหมดแล้ว เขาเลือกที่จะส่งคำสั่งซื้อ หน้าเว็บจะแปลงข้อมูลทั้งหมดเป็นชุดข้อมูลที่ประกอบด้วย DataTable สองชุด หนึ่งชุดสำหรับการสั่งซื้อและอีกชุดหนึ่งสำหรับการสั่งซื้อ แทรก DataRow สำหรับคำสั่งซื้อ และแทรกแถวข้อมูลสามแถวสำหรับรายการใบสั่ง จากนั้นหน้าเว็บจะแสดงข้อมูลนี้กลับไปยังผู้ใช้อีกครั้ง ผูกการควบคุมข้อมูลกับชุดข้อมูลและถามคุณแน่ใจหรือไม่ ผู้ใช้ยืนยันคำขอและส่งไปยังเลเยอร์ตรรกะของแอปพลิเคชัน ชั้นตรรกะของแอปพลิเคชันจะตรวจสอบชุดข้อมูลเพื่อดูว่าฟิลด์ที่จำเป็นทั้งหมดมีค่าหรือไม่ และดำเนินการตรวจสอบว่าผู้ใช้มี US$ มากกว่า 1,000 รายการหรือไม่ 00 ในบิลคงค้าง หากทุกอย่างเป็นไปด้วยดี ชุดข้อมูลจะถูกส่งผ่านไปยังชั้นการเข้าถึงข้อมูล ซึ่งเชื่อมต่อกับฐานข้อมูลและสร้างคำสั่งแทรกจากข้อมูลชุดข้อมูล

การใช้ชุดข้อมูลด้วยวิธีนี้เป็นวิธีที่รวดเร็วและมีประสิทธิภาพในการสร้างแอปพลิเคชัน และใช้พลังของ Framework Class Library และความสามารถของ ASP.NET ในการผูกข้อมูลเข้ากับตัวควบคุมต่างๆ เช่น GridView กับชุดข้อมูล แทนที่จะใช้ออบเจกต์ชุดข้อมูลอย่างง่าย คุณสามารถใช้ออบเจกต์ชุดข้อมูลแบบพิมพ์และปรับปรุงประสบการณ์การเขียนโค้ดโดยการนำโค้ดไปใช้ในชั้นการนำเสนอ เช่นเดียวกับชั้นลอจิกของแอปพลิเคชัน ข้อดีของวิธีนี้ก็เป็นข้อเสียของวิธีการเช่นกัน การเปลี่ยนแปลงเล็กน้อยในโมเดลข้อมูลไม่จำเป็นต้องทำให้วิธีการหลายอย่างต้องเปลี่ยนลายเซ็น ดังนั้นในแง่ของการบำรุงรักษา วิธีนี้ใช้ได้ดีจริงๆ หากคุณจำได้ว่าชั้นการนำเสนอไม่จำเป็นต้องเป็นส่วนต่อประสานกับผู้ใช้ มันสามารถเป็น Web Service ได้เช่นกัน และหากคุณแก้ไขคำจำกัดความของชุดข้อมูล อาจเป็นเพราะคุณกำลังเปลี่ยนชื่อฟิลด์ในฐานข้อมูล แสดงว่าคุณกำลังแก้ไขสัญญาที่ underwrites บริการเว็บ อย่างที่คุณจินตนาการได้สิ่งนี้สามารถนำไปสู่ปัญหาที่สำคัญบางอย่างได้ สถานการณ์นี้ทำงานได้ดีหากเลเยอร์การนำเสนอเป็นเพียงส่วนต่อประสานกับผู้ใช้ แต่สำหรับส่วนต่อประสานกับระบบหรือส่วนประกอบภายนอก คุณจะต้องซ่อนการทำงานภายในของแอปพลิเคชันของคุณและแปลงข้อมูลเป็นอย่างอื่นที่ไม่ใช่การโคลนแบบจำลองข้อมูลโดยตรงและ คุณจะต้องสร้าง Data Transfer Objects (DTO)

การไหลของข้อมูลโดยใช้การแมปเชิงสัมพันธ์ของวัตถุ

โฟลว์ข้อมูลที่ใช้ ADO.NET เป็นวิธีการที่เน้นข้อมูลเป็นศูนย์กลางในการจัดการโฟลว์ข้อมูล ข้อมูลและตรรกะไม่ต่อเนื่องกัน อีกด้านหนึ่งของสเปกตรัมกำลังใช้วิธีการเชิงวัตถุมากขึ้น ที่นี่ ชั้นเรียนถูกสร้างขึ้นเพื่อจัดกลุ่มข้อมูลและพฤติกรรม เป้าหมายคือการกำหนดคลาสที่เลียนแบบข้อมูลและพฤติกรรมที่พบในโดเมนธุรกิจที่สร้างแอปพลิเคชัน ผลลัพธ์มักถูกอ้างถึงเป็นวัตถุทางธุรกิจ คอลเลกชันของวัตถุทางธุรกิจที่ประกอบเป็นแอปพลิเคชันเรียกว่าโมเดลโดเมน นักพัฒนาบางคนอ้างว่าโมเดลโดเมนที่สมบูรณ์ดีกว่าสำหรับการออกแบบตรรกะที่ซับซ้อนมากขึ้น เป็นการยากที่จะพิสูจน์หรือหักล้างคำกล่าวอ้างดังกล่าว แค่รู้ว่าคุณมีทางเลือกและขึ้นอยู่กับคุณที่จะทำมัน

รูปที่ 8-6 แสดงโฟลว์ข้อมูลที่คล้ายกับรูปที่ 8-5 ยกเว้นตอนนี้คุณได้เพิ่มเลเยอร์การแมปเชิงสัมพันธ์ของออบเจกต์และแทนที่ออบเจ็กต์ชุดข้อมูลด้วยพาหะข้อมูลที่แตกต่างกัน

ตอนนี้ทำทีละขั้นตอนเหมือนเดิม ลองจินตนาการว่ามีคนเชื่อมต่อกับร้านหนังสือของคุณและสั่งซื้อหนังสือสามเล่ม เลเยอร์การนำเสนอจัดการสถานะของตะกร้าสินค้า ลูกค้าพร้อมที่จะทำการสั่งซื้อและได้ให้ข้อมูลที่จำเป็นทั้งหมดแล้ว เขาเลือกที่จะส่งคำสั่งซื้อ หน้าเว็บเปลี่ยนข้อมูลทั้งหมดเป็น DTO เก็บข้อมูลสำหรับหนึ่งคำสั่งและสามบรรทัดคำสั่ง สร้างวัตถุตามต้องการ หน้าเว็บแสดงข้อมูลนี้กลับไปยังผู้ใช้อีกครั้ง ควบคุมการเชื่อมโยงข้อมูลกับ DTO โดยใช้ ObjectDataSource ใน ASP.NET 2.0 และถาม คุณแน่ใจหรือไม่ ผู้ใช้ยืนยันตัวเลือกและส่ง DTO ไปยังเลเยอร์ตรรกะของแอปพลิเคชัน ชั้นลอจิกของแอปพลิเคชันแปลง DTO เป็นวัตถุธุรกิจประเภท Order พร้อมคุณสมบัติเพื่อให้มีวัตถุ OrderLine สามรายการ วิธีการสั่งซื้อ Validate() ถูกเรียกเพื่อตรวจสอบความถูกต้องของคำสั่งซื้อและตรวจสอบว่าฟิลด์ที่จำเป็นทั้งหมดมีค่า และมีการตรวจสอบเพื่อระบุว่าผู้ใช้มีมากกว่า R$ 1,000.00 ในสลิปที่รอดำเนินการหรือไม่ ในการดำเนินการนี้ คำสั่งซื้อจะเรียก Order.Customer.GetOutstandingBills() หากทุกอย่างเรียบร้อยดี จะเรียกเมธอด Order.Save() คำขอจะผ่านเลเยอร์การแมปเชิงสัมพันธ์ของอ็อบเจ็กต์ โดยที่คำขอและแถวของคำขอถูกแมปกับ DataTable ในชุดข้อมูล และชุดข้อมูลจะถูกส่งผ่านไปยังเลเยอร์การเข้าถึงข้อมูล ซึ่งเชื่อมต่อกับฐานข้อมูลและสร้างคำสั่งแทรกจาก ข้อมูลในชุดข้อมูล แน่นอนว่ามีหลายวิธีที่การแมปเชิงวัตถุสามารถเกิดขึ้นได้ แต่ไม่ใช่ทุกวิธีที่จะรวมการแปลงเป็นชุดข้อมูล บางคนจะสร้างคำสั่งแทรกโดยตรง แต่ยังคงใช้เลเยอร์การเข้าถึงข้อมูลเพื่อดำเนินการคำสั่งนั้น

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

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

บริการตามสคีมา

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

แน่นอน คุณสามารถใช้อ็อบเจกต์ทางธุรกิจในเว็บแอปพลิเคชันและข้ามการแปลง DTO ได้ แต่โดยปกติแล้วจะใช้งานได้ดีก็ต่อเมื่อมีการใช้ตรรกะของแอปพลิเคชันพร้อมกับเว็บแอปพลิเคชัน จำไว้ว่า ในการเรียกใช้ Order.Save() คุณจะต้องใช้ การเชื่อมต่อฐานข้อมูล คุณต้องการสิ่งนี้หรือไม่นั้นขึ้นอยู่กับคุณและอาจเป็นผู้อำนวยการฝ่ายรักษาความปลอดภัยของคุณ