หลักการชี้นำของคุณไม่ควรซ้ำไปซ้ำมา :
ในวิศวกรรมซอฟต์แวร์ Don't Repeat Yourself (DRY) เป็นหลักการของการพัฒนาซอฟต์แวร์ที่มีวัตถุประสงค์เพื่อลดการซ้ำซ้อนของข้อมูลทุกชนิดโดยเฉพาะอย่างยิ่งมีประโยชน์ในสถาปัตยกรรมแบบหลายชั้น หลักการของ DRY นั้นระบุไว้ว่า "ความรู้ทุกชิ้นจะต้องมีการเป็นตัวแทนเพียงหนึ่งเดียวที่ไม่น่าสงสัยและมีอำนาจในระบบ"
ORM นั้นเป็นเลเยอร์พิเศษ (หรือระดับหากคุณต้องการ) โดยให้ความสะดวกสบายระหว่างแอปพลิเคชันของคุณกับที่เก็บข้อมูลของคุณ ข้อ จำกัด ของคุณควรอยู่ในที่เดียวและที่เดียวเท่านั้นไม่ว่าจะเป็น ORM หรือที่เก็บข้อมูลมิฉะนั้นจะเร็วพอที่คุณจะจบการบำรุงรักษาเวอร์ชันที่แตกต่างกัน คุณจริงๆไม่ต้องการที่จะทำเช่นนั้น
อย่างไรก็ตามในทางปฏิบัติ ORM ที่เหมาะสมครึ่งหนึ่งส่วนใหญ่จะสร้างโมเดลของคุณจากสคีมาข้อมูลของคุณโดยอัตโนมัติ แม้ว่าจะยังมีการทำซ้ำ แต่โอกาสในการบำรุงรักษาจะน้อยที่สุดเนื่องจากมีการสร้างรหัส ORM ซ้ำตามรูปแบบเดียวกันทุกครั้ง มันจะเหมาะที่จะไม่มีรหัสที่ซ้ำกัน แต่ข้อ จำกัด ที่สร้างขึ้นโดยอัตโนมัติเป็นสิ่งที่ดีที่สุดถัดไป
นอกจากนี้ยังมีข้อ จำกัด ของคุณในสถานที่หนึ่งไม่จำเป็นต้องหมายความว่าคุณควรจะมีทุกข้อ จำกัด ของคุณในสถานที่เดียวกัน บางข้อเช่นข้อ จำกัด ของ Referential Integrity อาจเหมาะสมกว่าสำหรับการจัดเก็บข้อมูล (แต่อาจหายไปหากคุณย้ายไปที่การจัดเก็บข้อมูลอื่น) และบางอย่างซึ่งส่วนใหญ่เกี่ยวข้องกับตรรกะทางธุรกิจที่ซับซ้อนจะเหมาะสมกว่าสำหรับ ORM ของคุณ มันจะดีกว่าถ้าคุณมีแอปเปิ้ลทั้งหมดในตะกร้าเดียวกัน แต่ ...
ความล้มเหลว
คุณพูดถึง ORM ที่ล้มเหลว นั่นไม่เกี่ยวข้องกับคำถามของคุณแอปพลิเคชันของคุณควรคิดถึง ORM และการจัดเก็บข้อมูลเป็นเอนทิตีเดียว ถ้ามันล้มเหลวมันล้มเหลวโดยการข้าม ORM เพื่อคุยกับที่จัดเก็บข้อมูลโดยตรงไม่ใช่ความคิดที่ดี
ข้าม ORM เพื่อสิ่งอื่น
ยังไม่ใช่ความคิดที่ดี อย่างไรก็ตามอาจเกิดขึ้นได้จากหลายสาเหตุ:
ส่วนดั้งเดิมของแอปพลิเคชันที่สร้างขึ้นก่อนที่ ORM จะได้รับการแนะนำ
นั่นเป็นสถานการณ์ที่ยากลำบากและสถานการณ์ที่ฉันต้องเผชิญในตอนนี้ดังนั้นฉันจึงพูดซ้ำ ๆ ว่า ไม่ว่าคุณจะดูแลส่วนที่ไม่ใช่ ORM หรือคุณเขียนใหม่เพื่อใช้ ORM ตัวเลือกที่สองอาจเหมาะสมกว่าในตอนแรก แต่เป็นการตัดสินใจที่ขึ้นอยู่กับว่าส่วนใดส่วนหนึ่งของแอปพลิเคชันของคุณกำลังดำเนินการ แต่เพียงผู้เดียว
ลองเปลี่ยนกุญแจในตาราง MySQL ขนาด 2 * 10 ^ 8 ที่ออกแบบมาไม่ดี (โดยไม่ต้องหยุดทำงาน) และคุณจะเข้าใจว่าฉันมาจากไหน
ส่วนที่ไม่ใช่มรดกของแอปพลิเคชันที่จำเป็นต้องพูดคุยกับที่จัดเก็บข้อมูลโดยตรง:
แม้จะมีเล่ห์เหลี่ยม ORMs เป็นเครื่องมือแฟนซีและพวกเขาดูแลเกือบทุกอย่าง แต่บางครั้งพวกเขาก็เข้าใกล้หรือไร้ประโยชน์อย่างแน่นอน buzzword (buzzphrase จริงๆ) นั้นไม่ตรงกับความต้านทานเชิงวัตถุสัมพันธ์ทำให้คุณไม่สามารถใช้ ORM ของคุณในการทำทุกอย่างที่ฐานข้อมูลเชิงสัมพันธ์ของคุณทำและสำหรับบางสิ่งที่พวกเขาทำ
ความคิดเห็น
จากจุดของความถูกต้องของข้อมูลข้อ จำกัด ต้องอยู่ในฐานข้อมูลและควรอยู่ในแอปพลิเคชัน จะเกิดอะไรขึ้นถ้าแอปพลิเคชันของคุณเข้าถึงได้จากเว็บและเดสก์ท็อปแอปพลิเคชันหรือแอพมือถือหรือเว็บเซอร์ - Luiz Damim
นี่คือที่เพิ่มเลเยอร์พิเศษจะเป็นประโยชน์อย่างยิ่งและถ้าเรากำลังพูดถึงเว็บแอปพลิเคชันฉันจะไปกับ REST API การออกแบบที่ง่ายเกินไปสำหรับสิ่งนี้จะเป็น:
ORM จะอยู่ระหว่าง API กับแหล่งเก็บข้อมูลและทุกอย่างที่อยู่เบื้องหลัง API (รวมถึง) จะถือว่าเป็นเอนทิตีเดียวจากแอปพลิเคชันต่างๆ