การกำหนดค่า XML เทียบกับการกำหนดค่าตามคำอธิบายประกอบ [ปิด]

ในโครงการขนาดใหญ่สองสามโครงการที่ฉันได้ดำเนินการเมื่อไม่นานมานี้ดูเหมือนว่าการเลือกโครงการใดโครงการหนึ่ง (XML หรือ Annotation) มีความสำคัญมากขึ้น เมื่อโครงการเติบโตขึ้นความสม่ำเสมอเป็นสิ่งสำคัญมากสำหรับการบำรุงรักษา

คำถามของฉันคืออะไรคือข้อดีของการกำหนดค่าที่ใช้ XML เหนือการกำหนดค่าตามคำอธิบายประกอบและอะไรคือข้อดีของการกำหนดค่าตามคำอธิบายประกอบผ่านการกำหนดค่าตาม XML

คำอธิบายประกอบมีการใช้งาน แต่ไม่ใช่สัญลักษณ์แสดงหัวข้อย่อยเงินเดียวที่จะฆ่าการกำหนดค่า XML ฉันแนะนำให้ผสมทั้งสองอย่าง!

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

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

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

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

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

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

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

ฉันมักจะคิดเกี่ยวกับคำอธิบายประกอบเป็นชนิดของตัวบ่งชี้ของบางสิ่งที่ชั้นเรียนมีความสามารถในหรือว่ามันมีปฏิสัมพันธ์กับคนอื่น ๆ

ในทางกลับกันการกำหนดค่า Spring XML สำหรับฉันก็คือการกำหนดค่า

ตัวอย่างเช่นข้อมูลเกี่ยวกับ ip และพอร์ตของพร็อกซีจะอยู่ในไฟล์ XML แน่นอนมันคือการกำหนดค่ารันไทม์

การใช้@Autowire, @Elementเพื่อบ่งชี้ถึงกรอบการทำงานว่าจะทำอย่างไรกับการเรียนคือการใช้ที่ดีของคำอธิบายประกอบ

การใส่ URL ลงใน@Webserviceคำอธิบายประกอบเป็นลักษณะที่ไม่ดี

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

ฉันใช้ Spring มาสองสามปีแล้วและปริมาณ XML ที่ต้องการนั้นน่าเบื่ออย่างแน่นอน ระหว่างสกีมา XML ใหม่และการสนับสนุนคำอธิบายประกอบใน Spring 2.5 ฉันมักจะทำสิ่งเหล่านี้:

1. การใช้ "component-scan" เพื่อโหลดคลาสอัตโนมัติซึ่งใช้ @Repository, @Service หรือ @Component ฉันมักจะตั้งชื่อถั่วทุกอันแล้วต่อเข้าด้วยกันโดยใช้ @Resource ฉันพบว่าท่อประปานี้ไม่ได้เปลี่ยนบ่อยนักดังนั้นคำอธิบายประกอบจึงสมเหตุสมผล

2. การใช้เนมสเปซ "aop" สำหรับ AOP ทั้งหมด นี่ใช้งานได้ดีจริงๆ ฉันยังคงใช้มันเพื่อทำธุรกรรมด้วยเพราะการใส่ @Transactional ไปทั่วสถานที่นั้นเป็นการลาก คุณสามารถสร้างพอยต์ช็อตที่ตั้งชื่อสำหรับเมธอดบนบริการหรือที่เก็บใด ๆ และใช้คำแนะนำได้อย่างรวดเร็ว

3. ฉันใช้ LocalContainerEntityManagerFactoryBean ร่วมกับ HibernateJpaVendorAdapter เพื่อกำหนดค่า Hibernate ซึ่งช่วยให้ไฮเบอร์เนตค้นหาคลาส @Entity โดยอัตโนมัติบน classpath ได้อย่างง่ายดาย จากนั้นฉันสร้างชื่อ SessionFactory bean โดยใช้ "factory-bean" และ "factory-method" ที่อ้างถึง LCEMFB

ส่วนสำคัญในการใช้วิธีการใส่คำอธิบายประกอบอย่างเดียวคือแนวคิดของ "ชื่อถั่ว" หายไปไม่มากก็น้อย (กลายเป็นไม่มีนัยสำคัญ)

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

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

ฉันคิดว่าการมองเห็นเป็นชัยชนะที่ยิ่งใหญ่ด้วยวิธีการตาม XML ฉันพบว่า XML ไม่ได้แย่ขนาดนั้นเนื่องจากมีเครื่องมือต่างๆสำหรับการนำทางเอกสาร XML (เช่นหน้าต่าง Visual Studio + ReSharper's File Structure)

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

ฉันไม่รู้; ในท้ายที่สุด XML Hell ก็ดูเหมือนจะไม่เลวร้ายสำหรับฉัน

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

• บวก: คำอธิบายประกอบเป็นเรื่องที่พูดน้อย
• ลบ: คำอธิบายประกอบจะมองเห็นได้น้อยลง

แล้วแต่คุณว่าอะไรสำคัญกว่ากัน ...

โดยทั่วไปแล้วฉันจะแนะนำให้เลือกวิธีใดวิธีหนึ่งและใช้กับผลิตภัณฑ์ที่ปิดบางส่วน ...

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

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

วิธีที่ฉันชอบคือการกำหนดค่าตาม Java ที่ไม่มีคำอธิบายประกอบ (หรือขั้นต่ำ) http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

ฉันอาจจะคิดผิด แต่ฉันคิดว่า Annotations (เช่นเดียวกับใน @Tag ของ Java และ [Attribute] ของ C #) เป็นตัวเลือกเวลาคอมไพล์และ XML เป็นตัวเลือกรันไทม์ สำหรับฉันแล้วมันไม่เทียบเท่าและมีข้อดีข้อเสียที่แตกต่างกัน

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

• คอนฟิกูเรชันเฉพาะเซิร์ฟเวอร์ (เช่นพา ธ สัมบูรณ์ไปยังรีซอร์สบนเซิร์ฟเวอร์): ไฟล์ Spring XML
• การฉีดถั่วเป็นสมาชิกของถั่วอื่น ๆ (หรือการนำค่าที่กำหนดโดย Spring XML มาใช้ในถั่วหลายชนิด): คำอธิบายประกอบ

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

ในขอบเขตของคอนเทนเนอร์ DI ฉันคิดว่า DI ที่ใช้คำอธิบายประกอบกำลังใช้การใช้คำอธิบายประกอบ Java ในทางที่ผิด ฉันไม่แนะนำให้ใช้อย่างแพร่หลายในโครงการของคุณ หากโครงการของคุณต้องการพลังของคอนเทนเนอร์ DI จริงๆฉันขอแนะนำให้ใช้ Spring IoC กับตัวเลือกการกำหนดค่าตาม Xml

หากเป็นเพียงเพื่อประโยชน์ในการทดสอบหน่วยนักพัฒนาควรใช้รูปแบบ Dependency Inject ในการเข้ารหัสและใช้ประโยชน์จากเครื่องมือจำลองเช่น EasyMock หรือ JMock เพื่อหลีกเลี่ยงการพึ่งพา

คุณควรพยายามหลีกเลี่ยงการใช้คอนเทนเนอร์ DI ในบริบทที่ไม่ถูกต้อง

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

โปรดดูลิงค์ต่อไปนี้ อาจมีประโยชน์เช่นกัน

1. คำอธิบายประกอบกับ XML ข้อดีและข้อเสีย
2. http://www.ibm.com/developerworks/library/j-cwt08025/

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

ฉันใช้ทั้งสองอย่าง XML ส่วนใหญ่ แต่เมื่อฉันมีถั่วจำนวนมากที่สืบทอดมาจากคลาสทั่วไปและมีคุณสมบัติทั่วไปฉันใช้คำอธิบายประกอบสำหรับสิ่งเหล่านั้นในคลาสระดับสูงดังนั้นฉันจึงไม่จำเป็นต้องตั้งค่าคุณสมบัติเดียวกันสำหรับถั่วแต่ละชนิด เนื่องจากฉันเป็นคนบ้าคลั่งในการควบคุมฉันจึงใช้ @Resource (name = "ferBean ") แทนที่จะเป็นเพียงการป้อนข้อมูลอัตโนมัติ (และช่วยตัวเองไม่ให้เดือดร้อนมากถ้าฉันต้องการถั่วอื่นในคลาสเดียวกับที่อ้างถึงดั้งเดิม) .

มีข้อดีข้อเสียของการกำหนดค่าคำอธิบายประกอบจากประสบการณ์ของฉัน:

• เมื่อพูดถึงการกำหนดค่า JPA เนื่องจากทำครั้งเดียวและมักจะไม่มีการเปลี่ยนแปลงบ่อยนักฉันชอบที่จะยึดติดกับการกำหนดค่าคำอธิบายประกอบ อาจมีข้อกังวลเกี่ยวกับความเป็นไปได้ที่จะเห็นภาพรวมของการกำหนดค่าที่ใหญ่ขึ้น - ในกรณีนี้ฉันใช้ไดอะแกรม MSQLWorkbench
• การกำหนดค่า Xml นั้นดีมากในการรับภาพแอปพลิเคชันที่ใหญ่ขึ้น แต่อาจจะยุ่งยากในการค้นหาข้อผิดพลาดบางอย่างจนถึงรันไทม์ ในกรณีนี้คำอธิบายประกอบSpring @Configuration จะฟังดูเป็นตัวเลือกที่ดีกว่าเนื่องจากช่วยให้คุณเห็นภาพที่ใหญ่ขึ้นเช่นกันและยังช่วยให้ตรวจสอบการกำหนดค่าตามเวลาในการคอมไพล์
• สำหรับการกำหนดค่า Spring ฉันต้องการรวมทั้งสองวิธี: ใช้@Configurationคำอธิบายประกอบกับอินเทอร์เฟซ Services และ Query และการกำหนดค่า xml สำหรับ dataSource และ Spring configuration ต่างๆเช่นบริบท: component-scan base-package = "... "
• แต่การกำหนดค่า xml คำอธิบายประกอบ java บิตเมื่อพูดถึงการกำหนดค่าโฟลว์ (Spring Web Flow หรือ Lexaden Web Flow) เนื่องจากเป็นสิ่งสำคัญอย่างยิ่งที่จะต้องเห็นภาพรวมที่ใหญ่ขึ้นของกระบวนการทางธุรกิจทั้งหมด และฟังดูยุ่งยากที่จะนำไปใช้กับวิธีการใส่คำอธิบายประกอบ

ฉันชอบรวมทั้งสองวิธี - คำอธิบายประกอบ java และขั้นต่ำ xml ที่จำเป็นเพื่อลดการกำหนดค่านรก

สำหรับ Spring Framework ฉันชอบแนวคิดในการใช้คำอธิบายประกอบ @Component และการตั้งค่าตัวเลือก "component-scan" เพื่อให้ Spring สามารถค้นหา java beans ของฉันเพื่อที่ฉันจะได้ไม่ต้องกำหนด bean ทั้งหมดของฉันใน XML หรือใน JavaConfig ตัวอย่างเช่นสำหรับ java bean แบบซิงเกิลตันที่ไร้สัญชาติซึ่งจำเป็นต้องต่อสายเข้ากับคลาสอื่น ๆ (ผ่านอินเทอร์เฟซที่ดี) วิธีนี้ใช้ได้ดีมาก โดยทั่วไปสำหรับ Spring beans ฉันส่วนใหญ่ย้ายออกจาก Spring XML DSL สำหรับการกำหนดถั่วและตอนนี้นิยมใช้ JavaConfig และ Spring Annotations เนื่องจากคุณได้รับเวลารวบรวมการตรวจสอบการกำหนดค่าของคุณและการสนับสนุน refactoring บางส่วนที่คุณไม่ได้ทำ ไม่รับกับการกำหนดค่า Spring XML ฉันผสมทั้งสองอย่างในบางกรณีที่หายากซึ่งฉันพบว่า JavaConfig / Annotations ไม่สามารถทำสิ่งที่มีอยู่โดยใช้การกำหนดค่า XML

สำหรับ Hibernate ORM (ยังไม่ได้ใช้ JPA) ฉันยังคงชอบไฟล์การแมป XML เนื่องจากคำอธิบายประกอบในคลาสโมเดลโดเมนในระดับหนึ่งละเมิดThe Clean Architectureซึ่งเป็นรูปแบบสถาปัตยกรรมแบบแบ่งชั้นที่ฉันนำมาใช้ในช่วงไม่กี่ปีที่ผ่านมา การละเมิดเกิดขึ้นเนื่องจากต้องการให้ Core Layer ขึ้นอยู่กับสิ่งที่เกี่ยวข้องกับการคงอยู่เช่นไลบรารี Hibernate หรือ JPA และทำให้ POJO ของโมเดลโดเมนมีความคงอยู่น้อยลงเล็กน้อย ในความเป็นจริง Core Layer ไม่ควรขึ้นอยู่กับโครงสร้างพื้นฐานอื่นใดเลย

อย่างไรก็ตามหาก The Clean Architecture ไม่ใช่ "ถ้วยชา" ของคุณฉันจะเห็นว่ามีข้อดีอย่างแน่นอน (เช่นความสะดวกและความสามารถในการบำรุงรักษา) ของการใช้คำอธิบายประกอบ Hibernate / JPA ในคลาสโมเดลโดเมนบนไฟล์การแมป XML แยกต่างหาก