เมื่อเร็ว ๆ นี้ฉันได้อ่านบทความของ Mark Seemannเกี่ยวกับรูปแบบการต่อต้าน Service Locator

ผู้เขียนชี้ให้เห็นเหตุผลหลักสองประการที่ว่าทำไม ServiceLocator จึงต่อต้านรูปแบบ:

1. ปัญหาการใช้งาน API (ซึ่งฉันก็สบายดี)
   เมื่อคลาสใช้ตัวระบุตำแหน่งบริการมันยากมากที่จะเห็นการอ้างอิงเนื่องจากในกรณีส่วนใหญ่คลาสจะมีตัวสร้าง PARAMETERLESS เพียงตัวเดียว ในทางตรงกันข้ามกับ ServiceLocator วิธี DI เปิดเผยการอ้างอิงอย่างชัดเจนผ่านพารามิเตอร์ของตัวสร้างเพื่อให้เห็นการอ้างอิงได้ง่ายใน IntelliSense

2. ปัญหาการบำรุงรักษา (ซึ่งทำให้ฉันงง)
   พิจารณาตัวอย่างต่อไปนี้

เรามีคลาส'MyType'ซึ่งใช้วิธีการระบุตำแหน่งบริการ:

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();
    }
}

ตอนนี้เราต้องการเพิ่มการอ้างอิงอื่นให้กับคลาส 'MyType'

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

และนี่คือจุดเริ่มต้นของความเข้าใจผิดของฉัน ผู้เขียนกล่าวว่า:

มันยากกว่ามากที่จะบอกได้ว่าคุณกำลังแนะนำการเปลี่ยนแปลงที่ทำลายล้างหรือไม่ คุณต้องเข้าใจแอปพลิเคชันทั้งหมดที่ใช้ Service Locator และคอมไพเลอร์จะไม่ช่วยคุณ

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

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

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

อัปเดต (สรุป):

คำตอบสำหรับคำถามของฉัน "Is Service Locator an anti-pattern" ขึ้นอยู่กับสถานการณ์จริงๆ และแน่นอนฉันไม่แนะนำให้ตัดมันออกจากรายการเครื่องมือของคุณ อาจมีประโยชน์มากเมื่อคุณเริ่มจัดการกับรหัสเดิม หากคุณโชคดีพอที่จะอยู่ในจุดเริ่มต้นของโครงการแนวทาง DI อาจเป็นทางเลือกที่ดีกว่าเนื่องจากมีข้อได้เปรียบเหนือ Service Locator

และนี่คือความแตกต่างหลักที่ทำให้ฉันไม่ใช้ Service Locator สำหรับโครงการใหม่ของฉัน:

• ชัดเจนและสำคัญที่สุด: Service Locator ซ่อนการอ้างอิงคลาส
• หากคุณใช้คอนเทนเนอร์ IoC บางตัวอาจจะสแกนตัวสร้างทั้งหมดเมื่อเริ่มต้นเพื่อตรวจสอบการอ้างอิงทั้งหมดและให้ข้อเสนอแนะทันทีเกี่ยวกับการแมปที่ขาดหายไป (หรือการกำหนดค่าที่ไม่ถูกต้อง) เป็นไปไม่ได้หากคุณใช้คอนเทนเนอร์ IoC ของคุณเป็นตัวระบุตำแหน่งบริการ

สำหรับรายละเอียดอ่านคำตอบที่ยอดเยี่ยมซึ่งได้รับด้านล่าง

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

แต่เราต้องดูว่ามีรูปแบบการใช้งานที่ถูกต้องหรือไม่และสำหรับ Service Locator มีหลายกรณีการใช้งาน แต่เริ่มต้นด้วยการดูตัวอย่างที่คุณให้มา

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

ฝันร้ายของการบำรุงรักษาในคลาสนั้นคือการอ้างอิงถูกซ่อนไว้ หากคุณสร้างและใช้คลาสนั้น:

var myType = new MyType();
myType.MyMethod();

คุณไม่เข้าใจว่ามีการอ้างอิงหากซ่อนอยู่โดยใช้สถานที่ให้บริการ ตอนนี้ถ้าเราใช้การฉีดพึ่งพาแทน:

public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

    public void MyMethod()
    {
        dep1.DoSomething();

        // new dependency
        dep2.DoSomething();
    }
}

คุณสามารถระบุการอ้างอิงได้โดยตรงและไม่สามารถใช้คลาสก่อนที่จะทำให้พอใจได้

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

รูปแบบเป็นลายต่อต้านหรือไม่?

ไม่

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

แต่ตัวอย่างที่ดีกว่าคือ ASP.NET MVC และ WebApi คุณคิดว่าอะไรทำให้การฉีดแบบพึ่งพาเป็นไปได้ในตัวควบคุม? ถูกต้อง - สถานบริการ

คำถามของคุณ

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

มีปัญหาร้ายแรงอีกสองประการ:

1. ด้วยสถานที่ให้บริการคุณยังเพิ่มการอ้างอิงอื่น: ตัวระบุตำแหน่งบริการ
2. คุณจะทราบได้อย่างไรว่าควรมีการอ้างอิงตลอดอายุการใช้งานใดและควรทำความสะอาดอย่างไร / เมื่อใด

ด้วยการฉีดคอนสตรัคเตอร์โดยใช้คอนเทนเนอร์คุณจะได้รับสิ่งนั้นฟรี

หากเราอาจลืมตั้งค่า ServiceLocator เราอาจลืมเพิ่มการแมปใหม่ในคอนเทนเนอร์ IoC ของเราและวิธีการ DI อาจมีปัญหารันไทม์เหมือนกัน

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

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

นอกจากนี้ผู้เขียนยังกล่าวถึงปัญหาในการทดสอบหน่วย แต่เราจะไม่มีปัญหากับแนวทาง DI หรือไม่?

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

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

ดังนั้นเมื่อปรับโครงสร้างแอปพลิเคชันดั้งเดิมขนาดใหญ่เพื่อเริ่มใช้แนวคิด DI ฉันจะบอกว่าไม่เพียง แต่ Service Locator ไม่ใช่รูปแบบการต่อต้าน แต่เป็นวิธีเดียวที่จะค่อยๆนำแนวคิด DI ไปใช้กับฐานรหัส

จากมุมมองของการทดสอบตัวระบุตำแหน่งบริการไม่ดี ดูคำอธิบายดีๆของ Google Tech Talk ของ Misko Hevery พร้อมตัวอย่างโค้ดhttp://youtu.be/RlfLCWKxHJ0เริ่มต้นนาทีที่ 8:45 ฉันชอบการเปรียบเทียบของเขา: ถ้าคุณต้องการ $ 25 ให้ขอเงินโดยตรงแทนที่จะให้กระเป๋าเงินของคุณจากที่ที่จะนำเงินไป นอกจากนี้เขายังเปรียบเทียบ Service Locator กับกองหญ้าที่มีเข็มที่คุณต้องการและรู้วิธีดึงมัน ชั้นเรียนที่ใช้ Service Locator นั้นยากที่จะนำกลับมาใช้ใหม่เพราะมัน

ปัญหาการบำรุงรักษา (ซึ่งทำให้ฉันสงสัย)

มี 2 ​​สาเหตุที่แตกต่างกันว่าทำไมการใช้ตัวระบุตำแหน่งบริการจึงไม่ดีในเรื่องนี้

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

ธรรมดาและเรียบง่าย: คลาสที่มีตัวระบุตำแหน่งบริการอยู่ในนั้นยากที่จะใช้ซ้ำได้ยากกว่าคลาสที่ยอมรับการอ้างอิงผ่านตัวสร้าง

พิจารณากรณีที่คุณจำเป็นต้องใช้บริการจากLibraryAที่ผู้เขียนตัดสินใจที่จะใช้ServiceLocatorAและการบริการจากที่มีผู้เขียนตัดสินใจที่จะใช้LibraryB ServiceLocatorBเราไม่มีทางเลือกอื่นนอกจากการใช้ตัวระบุตำแหน่งบริการ 2 แห่งในโครงการของเรา ต้องกำหนดค่าการอ้างอิงจำนวนเท่าใดเป็นเกมที่คาดเดาหากเราไม่มีเอกสารที่ดีซอร์สโค้ดหรือผู้เขียนเกี่ยวกับการโทรด่วน หากตัวเลือกเหล่านี้ล้มเหลวเราอาจต้องใช้ตัวถอดรหัสเพียงอย่างเดียวเพื่อดูว่าการอ้างอิงคืออะไร เราอาจต้องกำหนดค่า API ตัวระบุตำแหน่งบริการ 2 รายการที่แตกต่างกันโดยสิ้นเชิงและขึ้นอยู่กับการออกแบบอาจเป็นไปไม่ได้ที่จะรวมคอนเทนเนอร์ DI ที่มีอยู่ของคุณ อาจเป็นไปไม่ได้เลยที่จะแบ่งปันอินสแตนซ์เดียวของการพึ่งพาระหว่างไลบรารีทั้งสอง ความซับซ้อนของโครงการอาจรวมกันมากขึ้นหากตัวระบุตำแหน่งบริการไม่ได้อาศัยอยู่ในไลบรารีเดียวกันกับบริการที่เราต้องการโดยปริยายเรากำลังลากการอ้างอิงไลบรารีเพิ่มเติมไปยังโครงการของเราโดยปริยาย

ตอนนี้พิจารณาสองบริการเดียวกันที่ทำด้วยการฉีดตัวสร้าง LibraryAเพิ่มการอ้างอิงถึง LibraryBเพิ่มการอ้างอิงถึง ระบุการอ้างอิงในการกำหนดค่า DI ของคุณ (โดยการวิเคราะห์สิ่งที่จำเป็นผ่าน Intellisense) เสร็จแล้ว

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

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

นี่คือย่อหน้าจากAdaptive Code ผ่าน C # :

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

- Hall, Gary McLean Adaptive Code ผ่าน C #: การเข้ารหัสแบบ Agile ด้วยรูปแบบการออกแบบและหลักการ SOLID (การอ้างอิงสำหรับนักพัฒนา) (น. 309) การศึกษาของเพียร์สัน.

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

การให้ลูกค้ายอมรับการอ้างอิงถึงบริการ (ไปยังการอ้างอิง) ผ่านอินเทอร์เฟซที่ชัดเจนคุณ

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

คุณคิดถูกแล้วที่ DI มีปัญหา / ข้อเสีย แต่ข้อดีที่กล่าวมานั้นมีมากกว่าพวกเขา ... IMO คุณพูดถูกว่า DI มีการพึ่งพาในอินเทอร์เฟซ (ตัวสร้าง) - แต่หวังว่าจะเป็นการพึ่งพาที่คุณต้องการและคุณต้องการให้มองเห็นได้และตรวจสอบได้

ใช่บริการค้นหาเป็นรูปแบบการป้องกันมันละเมิด encapsulationและของแข็ง