การวางแนววัตถุนั้นมีค่าเป็นพิเศษเพราะสถานการณ์ประเภทนี้เกิดขึ้นและมันให้เครื่องมือในการออกแบบสิ่งที่เป็นนามธรรมที่ช่วยให้คุณสามารถสรุปความซับซ้อนได้
คำถามจริงที่นี่คือที่คุณแค็ปซูลความซับซ้อนที่?
ดังนั้นให้ฉันย้อนกลับไปสักครู่แล้วพูดกับ 'ความซับซ้อน' ที่ฉันกำลังพูดถึงอยู่ที่นี่ ปัญหาของคุณ (ตามที่ฉันเข้าใจแก้ไขให้ถูกต้องถ้าฉันผิด) เป็นรูปแบบการคงอยู่ซึ่งไม่ใช่แบบจำลองที่ใช้งานได้อย่างมีประสิทธิภาพสำหรับงานที่คุณต้องกรอกข้อมูล มันอาจจะมีประสิทธิภาพและใช้งานได้สำหรับงานอื่น ๆ แต่ไม่ใช่สำหรับงานของคุณ
แล้วเราจะทำอย่างไรเมื่อเรามีข้อมูลที่ไม่มีแบบจำลองที่ดีสำหรับค่าเฉลี่ยของเรา
แปลภาษา. มันเป็นสิ่งเดียวที่คุณสามารถทำได้ การแปลนั้นเป็น 'ความซับซ้อน' ที่ฉันอ้างถึงข้างต้น ดังนั้นตอนนี้ที่เรายอมรับว่าเรากำลังจะแปลโมเดลเราต้องตัดสินใจด้วยปัจจัยสองสามประการ
เราจำเป็นต้องแปลทั้งสองทิศทางหรือไม่ ทั้งสองทิศทางจะได้รับการแปลเหมือนกันเช่นใน:
(Tbl A, Tbl B) -> Obj X (อ่าน)
Obj X -> (Tbl A, Tbl B) (เขียน)
หรือกิจกรรมการแทรก / อัปเดต / ลบแสดงวัตถุชนิดอื่นเช่นที่คุณอ่านข้อมูลเป็น Obj X แต่ข้อมูลถูกแทรก / อัปเดตจาก Obj Y หรือไม่ วิธีใดในสองวิธีที่คุณต้องการไปหรือหากไม่มีความเป็นไปได้ในการอัพเดต / แทรก / ลบเป็นปัจจัยสำคัญที่คุณต้องการทำการแปล
คุณแปลที่ไหน
กลับไปที่ข้อความแรกที่ฉันทำในคำตอบนี้ OO ช่วยให้คุณสามารถสรุปความซับซ้อนและสิ่งที่ฉันอ้างถึงในที่นี้คือความจริงที่ไม่เพียง แต่คุณ แต่คุณต้องสรุปความซับซ้อนนั้นหากคุณต้องการให้แน่ใจว่ามันจะไม่รั่วไหลและซึมเข้าไปในรหัสของคุณทั้งหมด ในขณะเดียวกันก็เป็นสิ่งสำคัญที่จะต้องตระหนักว่าคุณไม่สามารถมีสิ่งที่เป็นนามธรรมที่สมบูรณ์แบบได้ดังนั้นอย่ากังวลไปกว่าการมีสิ่งที่มีประสิทธิภาพและใช้งานได้ดี
อีกครั้งตอนนี้ ปัญหาของคุณคือ: คุณวางความซับซ้อนนี้ไว้ที่ไหน? คุณมีทางเลือก
คุณสามารถทำได้ในฐานข้อมูลโดยใช้กระบวนงานที่เก็บไว้ นี่เป็นข้อเสียเปรียบของการเล่น ORM ที่ไม่ค่อยดีนัก แต่ก็ไม่เป็นความจริงเสมอไป ขั้นตอนการจัดเก็บจะให้ประโยชน์บางอย่างรวมถึงประสิทธิภาพบ่อยครั้ง ขั้นตอนการจัดเก็บอาจต้องบำรุงรักษาเป็นจำนวนมาก แต่ก็ขึ้นอยู่กับคุณในการวิเคราะห์สถานการณ์เฉพาะของคุณและบอกว่าการบำรุงรักษาจะมากหรือน้อยกว่าตัวเลือกอื่น ๆ โดยส่วนตัวฉันมีทักษะมากในการจัดเก็บและด้วยเหตุนี้ความสามารถพิเศษที่มีอยู่นี้จึงช่วยลดค่าใช้จ่าย ไม่เคยประมาทค่าของการตัดสินใจขึ้นอยู่กับสิ่งที่คุณทำรู้ บางครั้งวิธีแก้ปัญหาแบบไม่ดีอาจดีกว่าโซลูชันที่ถูกต้องเพราะคุณหรือทีมของคุณรู้วิธีสร้างและบำรุงรักษาได้ดีกว่าโซลูชันที่ดีที่สุด
ตัวเลือกอื่นในฐานข้อมูลคือมุมมอง ขึ้นอยู่กับเซิร์ฟเวอร์ฐานข้อมูลของคุณสิ่งเหล่านี้อาจดีที่สุดหรือดีที่สุดย่อยหรือไม่มีประสิทธิภาพเลยข้อเสียข้อใดข้อหนึ่งอาจเป็นเวลาสืบค้นขึ้นอยู่กับตัวเลือกการทำดัชนีที่มีอยู่ในฐานข้อมูลของคุณ มุมมองกลายเป็นตัวเลือกที่ดียิ่งขึ้นถ้าคุณไม่จำเป็นต้องทำการแก้ไขข้อมูลใด ๆ (แทรก / อัพเดต / ลบ)
ก้าวผ่านฐานข้อมูลที่คุณมีสแตนด์บายเก่าของการใช้รูปแบบพื้นที่เก็บข้อมูล นี่เป็นวิธีการทดสอบตามเวลาที่มีประสิทธิภาพมาก ข้อเสียเปรียบมีแนวโน้มที่จะรวมถึงจานหม้อไอน้ำ แต่แหล่งเก็บข้อมูลที่ดีสามารถหลีกเลี่ยงจำนวนนี้และแม้เมื่อสิ่งเหล่านี้ส่งผลให้จานหม้อไอน้ำจำนวนมากโชคร้ายที่เก็บของมักจะเป็นรหัสง่าย ๆ ที่เข้าใจง่ายและบำรุงรักษารวมถึงการนำเสนอ API ที่ดี / นามธรรม นอกจากนี้ที่เก็บอาจเป็นประโยชน์สำหรับหน่วยทดสอบที่คุณเสียด้วยตัวเลือกในฐานข้อมูล
มีเครื่องมืออย่างผู้ทำแผนที่อัตโนมัติซึ่งอาจทำให้การใช้ ORM เป็นไปได้ซึ่งพวกเขาสามารถทำการแปลระหว่างฐานข้อมูลแบบจำลองจากแบบจำลอง ORM เป็นแบบจำลองที่ใช้งานได้ แต่เครื่องมือเหล่านี้บางอย่างอาจยุ่งยากในการรักษา / เข้าใจพฤติกรรม แม้ว่าพวกเขาจะสร้างรหัสค่าใช้จ่ายขั้นต่ำส่งผลให้ค่าใช้จ่ายในการบำรุงรักษาน้อยลงเมื่อเข้าใจเป็นอย่างดี
ถัดไปคุณกำลังก้าวไปอีกขั้นจากฐานข้อมูลซึ่งหมายความว่าจะมีโค้ดจำนวนมากขึ้นที่จะจัดการกับรูปแบบการคงอยู่ที่ไม่ได้แปลซึ่งจะไม่เป็นที่น่าพอใจอย่างแท้จริง ในสถานการณ์เหล่านี้คุณพูดถึงการวางเลเยอร์การแปลใน UI ของคุณซึ่งดูเหมือนว่าคุณกำลังทำอยู่ตอนนี้ นี่เป็นความคิดที่แย่มากและสลายไปตามกาลเวลา
ตอนนี้เริ่มพูดบ้ากันแล้ว
Objectไม่ได้เป็นเพียงสิ้นทั้งหมดเป็นนามธรรมทั้งหมดที่มีอยู่ มีความลึกซึ้งของ abstractions พัฒนามานานหลายปีที่วิทยาศาสตร์คอมพิวเตอร์ได้รับการศึกษาและแม้กระทั่งก่อนหน้านั้นจากการศึกษาคณิตศาสตร์ หากเรากำลังจะเริ่มสร้างความสร้างสรรค์ลองเริ่มพูดถึงสิ่งที่เป็นนามธรรมที่รู้จักซึ่งมีการศึกษา
มีโมเดลนักแสดงนี่เป็นวิธีการที่น่าสนใจเพราะมันบอกว่าสิ่งที่คุณทำคือการส่งข้อความไปยังโค้ดอื่นซึ่งมอบหมายงานทั้งหมดให้กับโค้ดอื่นนั้นได้อย่างมีประสิทธิภาพซึ่งมีประสิทธิภาพมากในการห่อหุ้มความซับซ้อนออกไปจากโค้ดทั้งหมดของคุณ สิ่งนี้สามารถทำงานได้ในขณะที่คุณส่งข้อความถึงนักแสดงที่พูดว่า "ฉันต้องการ Obj X ที่ส่งไปยัง Y" และคุณมีที่รองรับการตอบกลับที่ตำแหน่ง Y ซึ่งจะประมวลผล Obj X คุณสามารถส่งข้อความที่สั่ง "ฉันต้องการ Obj X และการคำนวณ Y, Z ทำได้แล้ว" จากนั้นคุณไม่จำเป็นต้องรอ การแปลจะเกิดขึ้นที่อีกด้านหนึ่งของข้อความผ่านและคุณสามารถดำเนินการต่อได้หากคุณไม่ต้องการอ่านผลลัพธ์ นี่อาจเป็นการดูถูกดูแคลนนักแสดงนางแบบเพื่อจุดประสงค์ของคุณ แต่ทั้งหมดขึ้นอยู่กับ;
ขอบเขตการห่อหุ้มก็คือขอบเขตกระบวนการ สิ่งเหล่านี้สามารถใช้เพื่อแยกความซับซ้อนอย่างมีประสิทธิภาพ คุณสามารถสร้างรหัสการแปลเป็นบริการเว็บที่การสื่อสารเป็น HTTP แบบง่ายโดยใช้ SOAP, REST หรือถ้าคุณต้องการโปรโตคอลของคุณเองจริงๆ (ไม่แนะนำ) STOMP ไม่ใช่โปรโตคอลใหม่ที่ไม่ดีเลย หรือใช้บริการ daemon ปกติกับไพพ์หน่วยความจำที่เผยแพร่ในระบบสำหรับการสื่อสารอย่างรวดเร็วอีกครั้งโดยใช้โปรโตคอลที่คุณเลือก นี่มีประโยชน์ที่ดีพอสมควร:
- คุณสามารถมีหลายกระบวนการที่รันการแปลสำหรับการสนับสนุนรุ่นเก่าและใหม่กว่าในเวลาเดียวกันช่วยให้คุณสามารถอัปเดตบริการแปลเพื่อเผยแพร่โมเดลวัตถุ V2 และแยกต่างหากในภายหลังอัปเดตรหัสบริโภคเพื่อทำงานกับวัตถุใหม่ แบบ
- คุณสามารถทำสิ่งที่น่าสนใจเช่นการตรึงกระบวนการไว้ที่แกนกลางเพื่อประสิทธิภาพคุณยังได้รับความปลอดภัยจำนวนมากในวิธีการนี้โดยทำให้กระบวนการเดียวที่ทำงานด้วยสิทธิ์ด้านความปลอดภัยเพื่อสัมผัสข้อมูลนั้น
- คุณจะได้รับขอบเขตที่แข็งแกร่งมากเมื่อคุณพูดถึงขอบเขตของกระบวนการที่จะคงที่เพื่อให้แน่ใจว่าการรั่วไหลของสิ่งที่เป็นนามธรรมน้อยที่สุดของคุณเป็นเวลานานเพราะการเขียนโค้ดในพื้นที่การแปลจะไม่สามารถเรียกนอกพื้นที่แปลได้ จะไม่เปิดเผยขอบเขตกระบวนการให้มั่นใจว่าชุดสถานการณ์การใช้งานคงที่ตามสัญญา
- ความสามารถในการอัปเดตแบบอะซิงโครนัส / ไม่มีการปิดกั้นนั้นง่ายขึ้น
ข้อเสียคือการบำรุงรักษามากกว่าที่จำเป็นโดยทั่วไปค่าใช้จ่ายในการสื่อสารที่ส่งผลต่อประสิทธิภาพและการบำรุงรักษา
มีหลายวิธีในการห่อหุ้มความซับซ้อนที่อาจทำให้ความซับซ้อนนั้นถูกวางไว้ในสถานที่แปลกและอยากรู้อยากเห็นมากขึ้นในระบบของคุณ การใช้รูปแบบของฟังก์ชั่นการสั่งซื้อที่สูงขึ้น (บ่อยครั้งที่แกล้งทำโดยใช้รูปแบบกลยุทธ์หรือรูปแบบวัตถุแปลก ๆ อื่น ๆ ) คุณสามารถทำสิ่งที่น่าสนใจมาก
ใช่แล้วเรามาเริ่มพูดถึง monad กัน คุณสามารถสร้างเลเยอร์การแปลนี้ในลักษณะที่เป็นอิสระอย่างมากของฟังก์ชั่นเฉพาะขนาดเล็กที่จำเป็นต้องทำการแปลอิสระ แต่ซ่อนฟังก์ชั่นการแปลทั้งหมดที่มองไม่เห็นออกไปเพื่อให้พวกเขาเข้าถึงรหัสภายนอกได้ยาก สิ่งนี้มีประโยชน์ในการลดการพึ่งพาพวกเขาทำให้พวกเขาสามารถเปลี่ยนแปลงได้ง่ายโดยไม่มีผลกับโค้ดภายนอกจำนวนมาก จากนั้นคุณสร้างคลาสที่รับฟังก์ชั่นการสั่งซื้อที่สูงขึ้น (ฟังก์ชั่นที่ไม่ระบุชื่อฟังก์ชั่นแลมบ์ดา, ออบเจกต์กลยุทธ์ แต่คุณจำเป็นต้องจัดโครงสร้างให้) ซึ่งทำงานกับวัตถุประเภทโมเดล OO ที่ดี จากนั้นให้โค้ดพื้นฐานที่ยอมรับฟังก์ชั่นเหล่านั้นทำการประมวลผลตามตัวอักษรโดยใช้วิธีการแปลที่เหมาะสม
สิ่งนี้จะสร้างขอบเขตที่การแปลทั้งหมดไม่เพียง แต่อยู่ในอีกด้านหนึ่งของขอบเขตห่างจากโค้ดทั้งหมดของคุณ มันถูกใช้ในด้านนั้นเท่านั้นทำให้โค้ดที่เหลือของคุณไม่รู้อะไรเลยนอกจากที่จุดเข้าใช้สำหรับขอบเขตนั้น
โอเคใช่ที่พูดถึงคนบ้าจริง ๆ แต่ใครจะรู้ คุณอาจเป็นคนบ้าคลั่ง (อย่างจริงจังอย่าทำพระด้วยคะแนนบ้าคลั่งต่ำกว่า 88% มีความเสี่ยงต่อการบาดเจ็บทางร่างกาย)