เมื่อไม่ใช้ Spring เพื่อยกตัวอย่างถั่ว


14

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

อาจเป็นตัวอย่างรหัสต่อไปนี้จะช่วยให้คุณเข้าใจภาวะที่กลืนไม่เข้าคายไม่ออกของฉัน:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

หากฉันกำหนดค่าสปริงมันจะกลายเป็นสิ่งที่ชอบ:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

โดยส่วนตัวฉันคิดว่าการใช้ Spring ที่นี่เป็นค่าใช้จ่ายที่ไม่จำเป็นเพราะ

  1. รหัสที่ง่ายต่อการอ่าน / ทำความเข้าใจ
  2. มันไม่ใช่สถานที่ที่ดีสำหรับการพึ่งพาการฉีดเพราะฉันไม่ได้คาดหวังว่าจะมีการใช้งานที่หลากหลาย / หลากหลายClassAซึ่งฉันต้องการอิสระที่จะแทนที่การใช้การกำหนดค่าสปริงในเวลาต่อมา

ฉันคิดถูกไหม ถ้าไม่ฉันจะไปไหนผิด

คำตอบ:


14

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


9

ฉันจะใช้ Spring (หรือระบบ DI อื่น) ระหว่างเลเยอร์การสร้างอินสแตนซ์โดยตรงภายในเลเยอร์
ดังนั้นคลาสที่สร้าง bean ที่ออกจากขอบเขตของคลาสนั้นไปยังระบบภายนอก (ตามหน้าที่) บางระบบซึ่งอาจถูกกำหนดโดยระบบนั้นหรือเลเยอร์การสื่อสารบางส่วนจะถูกสร้างผ่าน DI ถั่วอื่นที่สร้างขึ้นอย่างหมดจดเพื่อใช้ภายในภายในชั้นแอปพลิเคชันนั้นถูกสร้างขึ้นโดยตรงเพื่อความชัดเจนของรหัสและเหตุผลในการปฏิบัติงาน (ในระบบขนาดใหญ่ที่สำคัญ)


นี่เป็นคำตอบที่ถูกต้องสำหรับฉัน! น่าเศร้าที่ฉันเลือกได้เพียงคำตอบเดียว
Rishabh

1

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

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


สวัสดี Donal คำตอบของคุณจะเหมือนกันไหมถ้า ClassA เป็นโดเมนระดับที่อุดมไปด้วยตรรกะทางธุรกิจ
Sameer Patil

0

ฉันอาจผิดโปรดแก้ไขให้ถูกต้อง

แนวคิดทั้งหมดของ Bean ในบริบทของฤดูใบไม้ผลิคือ Spring Container กำลังดูแลวัตถุ มันเกิดมาเป็นขอบเขตการตายตลอดชีวิต ฯลฯ ... มันเหมือนกับว่ามันเป็นผู้ดูแลวัตถุ แอปพลิเคชั่นที่ต้องการมันอัดแน่น

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

ตามที่แนะนำไว้ก่อนหน้าวัตถุ dao jms จัดคิววัตถุ ฯลฯ นั้นหนักและดีกว่าจากผู้เชี่ยวชาญที่เป็น Spring framework ที่จะดูแล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.