การพักอาศัยการดำเนินการไม่เชื่อเรื่องพระเจ้าคุ้มค่าหรือไม่

ฉันมีโครงการที่ฉันกำลังใช้งานอยู่ในปัจจุบันโดยใช้ Tomcat, Spring 4, Spring Security, MySQL, และ JPA w / Hibernate

ฉันเลือก JPA จากมุมมองที่ว่าควรทำการสลับการใช้งานพื้นฐานของผู้ให้บริการ ORM อย่างราบรื่นหรืออย่างน้อยก็เจ็บปวดน้อย ฉันจะบอกว่านี่คือการใช้จิตใจ spec มากกว่าการใช้งาน (JAX-RS) เป็นจุดเริ่มต้นของชุมชนการพัฒนา Java

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

ส่วนหนึ่งของความกังวลของฉันมาจากความคิดของ YAGNI ฉันกำลังเขียนโปรแกรมในรูปแบบและแฟชั่นที่เฉพาะเจาะจง (โดยใช้ JPA แทน Hibernate) เพื่อที่ในอนาคตฉันสามารถสลับการใช้งาน ORM ของฉันได้ ฉันสงสัยอย่างมากว่าจะเกิดขึ้นตลอดอายุการใช้งานของผลิตภัณฑ์ดังนั้นฉันจึงใช้ความพยายามในสิ่งที่ฉันอาจไม่ได้รับประโยชน์จาก

คุณคิดยังไง? "การเขียนโปรแกรมไปยังอินเทอร์เฟซ" นั้นคุ้มค่าหรือไม่เมื่อพูดถึง JPA คุณเคยเปลี่ยนการใช้งาน ORM ทั้งหมดในผลิตภัณฑ์หรือไม่? คุณเคยสามารถหลีกเลี่ยงสิ่งที่เป็นนามธรรมจาก JPA ที่รั่วไหลไปได้หรือไม่? ฉันเองมีการเรียกใช้ SQL ดั้งเดิมเพียงตัวเดียว (เพื่อล้างตารางฐานข้อมูล) และมีบางสิ่งที่ฉันต้องการ futz ที่สร้างไว้ในข้อมูลจำเพาะ JPA (รับ / ตั้งค่าคำนำหน้ากับวิธีการของคุณและความแตกต่างระหว่างสมาชิกของ / ในซึ่งมีผลผูกมัดตัวฉันเองกับการใช้งานพื้นฐานจะทำให้ฉันมีโอกาสหลีกเลี่ยง

ดังนั้นในบางช่วงในอนาคตฉันสามารถสลับการใช้งาน ORM ของฉันได้ ฉันสงสัยอย่างรุนแรงว่าจะเกิดขึ้นตลอดอายุการใช้งานของผลิตภัณฑ์ดังนั้นฉันจึงใช้ความพยายามในสิ่งที่ฉันอาจไม่ได้รับประโยชน์จาก

จากประสบการณ์ของฉันโครงการองค์กรทั่วไปไม่เคยสลับกันเลย:

1. ฐานข้อมูล
2. ออม
3. ภาษา

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

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

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

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

สำหรับคนส่วนใหญ่ที่เขียนแอปพลิเคชัน Java นั้นส่วนใหญ่ไม่เกี่ยวข้อง

จากประสบการณ์ของฉัน: ไม่มันไม่คุ้มค่าในกรณีของ JPA / Hibernate

"การเขียนโปรแกรมไปยังอินเทอร์เฟซ" นั้นคุ้มค่าหรือไม่เมื่อพูดถึง JPA

เป็น แต่ไม่มีอะไรเกี่ยวข้องกับ JPA โดยเฉพาะ คุณสามารถทำการ "ตั้งโปรแกรมอินเทอร์เฟซ" ของ Hibernate ได้ นี้ไม่ได้เกี่ยวกับการซ่อนกรอบภายใต้มาตรฐานก็เป็นเรื่องเกี่ยวกับSOLID

คุณเคยเปลี่ยนการใช้งาน ORM ทั้งหมดในผลิตภัณฑ์หรือไม่?

ใช่และไม่. หนึ่งในผลิตภัณฑ์ของ บริษัท ของเราได้ย้ายจาก Hibernate ไปเป็น jOOQ บางส่วน (ซึ่งไม่เกี่ยวข้องกับ JPA) มันไม่ได้เป็น "โครงการขององค์กรทั่วไป" ที่ @cenenheim พูดถึงดังนั้นการแลกเปลี่ยนจึงเป็นไปได้

ฉันไม่เห็นจุดแลกเปลี่ยนไฮเบอร์เนตกับ ORM ที่สอดคล้องกับมาตรฐาน JPA อื่น

คุณเคยสามารถหลีกเลี่ยงสิ่งที่เป็นนามธรรมจาก JPA ที่รั่วไหลไปได้หรือไม่?

ไม่มันเป็นไปไม่ได้เพราะ JPA และ Hibernate นั้นซับซ้อนมาก และคุณต้องจัดการกับปัญหาด้านประสิทธิภาพและการออกแบบของ Hibernate

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

ปัญหาไม่มากนักในการสลับ ORM หรือผู้ให้บริการฐานข้อมูลของคุณเช่นนี้ มันเป็นปัญหาของการแยกจากความกังวลและอยู่อย่างคล่องตัว

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

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

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

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

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

ฉันยังเสียเวลาในการแปลงซอฟต์แวร์ที่ไม่มีใครคาดว่าจะต้องมีการแปลง

การสังเกตที่แท้จริงเพียงอย่างเดียวที่ฉันต้องทำคืออดีตนั้นเจ็บปวดน้อยกว่ามาก