โมดูลที่ต้องการเทียบกับการฉีดพึ่งพาใน Javascript


24

วันนี้มีคำถามโผล่ในใจของฉัน:

วิธีที่เราใช้ Javascript กับเกือบทุกอย่างที่ถือว่าเป็นแนวปฏิบัติที่ดีในการพัฒนาซอฟต์แวร์แบบดั้งเดิมหรือไม่?

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

โมดูลที่ต้องการ

รหัส Javascript มาตรฐานทุกวันนี้ดูเหมือนว่า:

const someModule = require('./someModule')

module.exports = function doSomethingWithRequest() {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

ข้อดี

  • การห่อหุ้ม: โมดูลทำงานแบบสแตนด์อโลนและรู้ทุกอย่างที่จำเป็นในการทำหน้าที่ของมัน
  • ลูกค้าสามารถใช้โมดูลได้ง่ายขึ้น

ข้อเสีย

  • การตรวจสอบได้แย่: นี่คือมาตรฐานเมื่อไม่ได้ใช้ DI แต่ในภาษาแบบไดนามิกเช่นจาวาสคริปต์ไว้ก็สามารถโกง * โดยโมดูลเหมือนหรือmockeryrewire
  • แน่นอนมันละเมิดกรม - ไม่ต้องสับสนกับการพึ่งพาการฉีด - เนื่องจากฉันสามารถนำเข้าโมดูลที่เป็นรูปธรรมได้เท่านั้น
  • มันอาจละเมิดOCP - ตัวอย่างเช่นสมมติว่าฉันมีโมดูลบันทึกที่เขียนไปยังระบบไฟล์ (ผ่านfsโมดูล) ถ้าฉันต้องการขยายโมดูลบันทึกนี้เพื่อส่งไปยังเครือข่ายมันจะยากมาก

* สิ่งนี้อาจทำงานร่วมกับ CommonJS หรือโมดูลของ AMD ได้เนื่องจากส่วนใหญ่จะใช้งานในพื้นที่ของผู้ใช้ อย่างไรก็ตามฉันไม่แน่ใจว่ามันจะเป็นไปได้อย่างไรด้วยimportไวยากรณ์ES6

ฉีดพึ่งพา

การใช้การฉีดพึ่งพามันจะเป็นเหมือน:

module.exports = function doSomethingWithRequest(someModule) {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

ข้อดี

  • เพิ่มความสามารถในการทดสอบ: ตอนนี้การ stub / mock ง่ายขึ้นsomeModuleแม้ใช้ไวยากรณ์ ES6
  • เป็นไปได้ที่จะให้เกียรติจุ่ม: ไม่จำเป็นว่าเป็นเพราะโมดูลลูกค้ายังสามารถตั้งโปรแกรมให้กับการใช้งานและไม่ได้เป็นส่วนต่อประสาน

ข้อเสีย

  • การห่อหุ้มที่ใช้งานไม่ได้: คำถามหลักที่เหลืออยู่คือ:

    ตกลงแล้วใครจะเป็นผู้สร้าง / ต้องการการพึ่งพา?

  • ทำที่ลูกค้าของโมดูลทุกดูเหมือนมากWET
  • นี่อาจจะทำให้ฉันต้องใช้ DI Container เพื่อให้เป็นไปได้ในโครงการจริง

ดังนั้นคำถามจริงที่นี่คือ:

ทำไมนักพัฒนา Javascript มีแนวโน้มที่จะพึ่งพาวิธีแรก?

นี่เป็นเพียง "วิธี Javascript" หรือไม่

ตัวฉันเองเขียนโค้ดแบบนี้บ่อยครั้ง ฉันมีส่วนแบ่งการตั้งค่าการทดสอบที่เป็นธรรมโดยใช้ห้องสมุดที่เยาะเย้ย แต่มันก็รู้สึกผิดอยู่เสมอ

ฉันพลาดอะไรไปรึเปล่า?


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

คำตอบ:


6

ฉันเป็นโปรแกรมเมอร์ PHP เป็นหลัก แต่มีการติดต่อกับ 4 ทีม JavaScript สำหรับปีที่ผ่านมาหรือดังนั้น

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

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

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

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

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