เหตุใดฉันจึงต้องใช้คอนเทนเนอร์ IoC แทนรหัส DI ที่ตรงไปตรงมา [ปิด]

ฉันใช้Dependency Injection (DI) มาระยะหนึ่งแล้วฉีดทั้งใน constructor, property หรือ method ฉันไม่เคยรู้สึกว่าต้องใช้คอนเทนเนอร์Inversion of Control (IoC) อย่างไรก็ตามยิ่งฉันอ่านมากขึ้นเท่าไหร่ฉันก็ยิ่งรู้สึกว่าชุมชนใช้คอนเทนเนอร์ IoC มากขึ้นเท่านั้น

ฉันเล่นกับภาชนะ .NET เช่นStructureMap , Ninject , ความสามัคคีและFunq ฉันยังคงล้มเหลวในการดูว่าคอนเทนเนอร์ IoC จะได้รับประโยชน์ / ปรับปรุงรหัสของฉันอย่างไร

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

กรุณาโน้มน้าวฉันว่าฉันต้องใช้คอนเทนเนอร์ IoC ฉันจะใช้ข้อโต้แย้งเหล่านี้เมื่อฉันพูดคุยกับนักพัฒนาเพื่อนในที่ทำงาน

ว้าวไม่น่าเชื่อว่าโจเอลจะชอบสิ่งนี้:

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

มากกว่านี้:

var svc = IoC.Resolve<IShippingService>();

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

คอนเทนเนอร์ IoC นั้นซับซ้อนใช่ไหม แต่สำหรับกรณีนี้ฉันได้แสดงว่ามันง่ายอย่างไม่น่าเชื่อ

เอาล่ะเรามาพิสูจน์เรื่องนี้กันดีกว่า สมมติว่าคุณมีเอนทิตีหรือวัตถุรูปแบบที่คุณต้องการผูกไว้กับ UI แบบอัจฉริยะ UI อัจฉริยะนี้ (เราจะเรียกมันว่า Shindows Morms) ต้องการให้คุณใช้ INotifyPropertyChanged เพื่อให้สามารถเปลี่ยนแปลงการติดตามและอัปเดต UI ได้

"ตกลงนั่นมันฟังดูไม่ค่อยดี" ดังนั้นคุณจึงเริ่มเขียน

คุณเริ่มต้นด้วยสิ่งนี้:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime CustomerSince { get; set; }
    public string Status { get; set; }
}

.. และจบลงด้วยสิ่งนี้ :

public class UglyCustomer : INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            string oldValue = _firstName;
            _firstName = value;
            if(oldValue != value)
                OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            string oldValue = _lastName;
            _lastName = value;
            if(oldValue != value)
                OnPropertyChanged("LastName");
        }
    }

    private DateTime _customerSince;
    public DateTime CustomerSince
    {
        get { return _customerSince; }
        set
        {
            DateTime oldValue = _customerSince;
            _customerSince = value;
            if(oldValue != value)
                OnPropertyChanged("CustomerSince");
        }
    }

    private string _status;
    public string Status
    {
        get { return _status; }
        set
        {
            string oldValue = _status;
            _status = value;
            if(oldValue != value)
                OnPropertyChanged("Status");
        }
    }

    protected virtual void OnPropertyChanged(string property)
    {
        var propertyChanged = PropertyChanged;

        if(propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(property));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

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

เคยได้ยินคำว่าทำงานฉลาดขึ้นหรือไม่?

ลองนึกภาพคนที่ฉลาดในทีมของคุณขึ้นมาแล้วพูดว่า: "นี่เป็นวิธีที่ง่ายกว่า"

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

ขึ้นอยู่กับเครื่องมือ IoC ที่คุณใช้คุณสามารถทำสิ่งที่มีลักษณะดังนี้:

var bindingFriendlyInstance = IoC.Resolve<Customer>(new NotifyPropertyChangedWrapper());

เกย์! คู่มือทั้งหมด INotifyPropertyChanged BS นั้นจะถูกสร้างขึ้นโดยอัตโนมัติสำหรับคุณในทุกตัวตั้งค่าคุณสมบัติเสมือนของวัตถุที่เป็นปัญหา

ความมหัศจรรย์นี้หรือไม่? ใช่ ! หากคุณเชื่อถือได้ว่ารหัสนี้ทำงานได้คุณสามารถข้ามคุณสมบัติทั้งหมดที่ห่อ mumbo-jumbo ได้อย่างปลอดภัย คุณมีปัญหาทางธุรกิจในการแก้ไข

การใช้เครื่องมือ IoC ที่น่าสนใจอื่น ๆ ในการทำ AOP:

• การทำธุรกรรมฐานข้อมูลการประกาศ & ซ้อน
• หน่วยงานประกาศ & ซ้อน
• เข้าสู่ระบบ
• เงื่อนไขก่อน / หลัง (ออกแบบตามสัญญา)

ฉันอยู่กับคุณวาดิม คอนเทนเนอร์ IoC ใช้แนวคิดที่เรียบง่ายสง่างามและมีประโยชน์และทำให้เป็นสิ่งที่คุณต้องศึกษาเป็นเวลาสองวันด้วยคู่มือ 200 หน้า

ฉันรู้สึกสับสนว่าชุมชน IoC นำบทความที่สวยงามและสง่างามโดยมาร์ตินฟาวเลอร์และเปลี่ยนมันเป็นกรอบซับซ้อนที่มักจะมีคู่มือ 200-300 หน้า

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

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

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

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

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

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

หากคุณใช้คอนเทนเนอร์ DI ให้ใช้คุณสมบัติที่คุณต้องการเท่านั้น ข้ามไฟล์คอนฟิกูเรชัน XML และกำหนดค่าเป็นรหัสหากเพียงพอ ติดกับตัวสร้างการฉีด พื้นฐานของ Unity หรือ StructureMap สามารถย่อให้เล็กลงได้ไม่กี่หน้า

มีการโพสต์บล็อกที่ยอดเยี่ยมโดย Mark Seemann ในเรื่องนี้: เมื่อใดควรใช้ DI Container

ในความเห็นของฉันประโยชน์อันดับหนึ่งของ IoC คือความสามารถในการรวมศูนย์การกำหนดค่าการพึ่งพาของคุณ

หากคุณกำลังใช้การพึ่งพาการฉีดโค้ดของคุณอาจมีลักษณะเช่นนี้

public class CustomerPresenter
{
  public CustomerPresenter() : this(new CustomerView(), new CustomerService())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

หากคุณใช้คลาส IoC แบบคงที่ซึ่งตรงข้ามกับ, IMHO ยิ่งแฟ้มการกำหนดค่าที่สับสนมากขึ้นคุณอาจมีสิ่งต่อไปนี้:

public class CustomerPresenter
{
  public CustomerPresenter() : this(IoC.Resolve<ICustomerView>(), IoC.Resolve<ICustomerService>())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

จากนั้นคลาส Static IoC ของคุณจะมีลักษณะเช่นนี้ฉันใช้ Unity ที่นี่

public static IoC
{
   private static readonly IUnityContainer _container;
   static IoC()
   {
     InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerView, CustomerView>();
      _container.RegisterType<ICustomerService, CustomerService>();
      // all other RegisterTypes and RegisterInstances can go here in one file.
      // one place to change dependencies is good.
   }
}

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

public void GetPresenter()
{
    var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}

class CustomerPresenter
{
    private readonly ICustomerService service;
    public CustomerPresenter(ICustomerService service)
    {
        this.service = service;
    }
}

class CustomerService
{
    private readonly IRespository<Customer> repository;
    public CustomerService(IRespository<Customer> repository)
    {
        this.repository = repository;
    }
}

class CustomerRepository : IRespository<Customer>
{
    private readonly DB db;
    public CustomerRepository(DB db)
    {
        this.db = db;
    }
}

class DB { }

หากคุณมีการอ้างอิงทั้งหมดเหล่านี้โหลดและคอนเทนเนอร์ IoC คุณสามารถแก้ไข CustomerService และการพึ่งพาลูกทั้งหมดจะได้รับการแก้ไขโดยอัตโนมัติ

ตัวอย่างเช่น:

public static IoC
{
   private IUnityContainer _container;
   static IoC()
   {
       InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerService, CustomerService>();
      _container.RegisterType<IRepository<Customer>, CustomerRepository>();
   }

   static T Resolve<T>()
   {
      return _container.Resolve<T>();
   }
}

public void GetPresenter()
{
   var presenter = IoC.Resolve<CustomerPresenter>();
   // presenter is loaded and all of its nested child dependencies 
   // are automatically injected
   // -
   // Also, note that only the Interfaces need to be registered
   // the concrete types like DB and CustomerPresenter will automatically 
   // resolve.
}

ฉันเป็นแฟนตัวยงของการเขียนโปรแกรมที่ประกาศ (ดูจำนวนคำถาม SQL ที่ฉันตอบ) แต่คอนเทนเนอร์ IoC ที่ฉันได้ดูดูเหมือนจะผิดเพี้ยนไปเพื่อประโยชน์ของพวกเขาเอง

... หรือบางทีผู้พัฒนาคอนเทนเนอร์ IoC อาจไม่สามารถเขียนเอกสารที่ชัดเจนได้

... หรืออย่างอื่นทั้งสองเป็นจริงในระดับหนึ่งหรืออื่น

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

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

การใช้คอนเทนเนอร์เป็นส่วนใหญ่เกี่ยวกับการเปลี่ยนจากรูปแบบที่จำเป็น / สคริปต์ของการเริ่มต้นและการกำหนดค่าเป็นหนึ่งที่เปิดเผย สิ่งนี้อาจมีผลประโยชน์แตกต่างกันเล็กน้อย:

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

แน่นอนว่าอาจมีปัญหา:

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

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

ดังนั้นคุณมีรหัสที่ใช้งานได้แล้ว และกำลังสงสัยว่าทำไมคุณต้องการแทนที่ด้วยการใช้งานของคนอื่น

ข้อดีสำหรับการพิจารณาคอนเทนเนอร์ IoC ของบุคคลที่สาม

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

จุดด้อย

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

ดังนั้นชั่งน้ำหนักข้อดีข้อเสียของคุณและตัดสินใจ

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

ค่าที่คุณได้รับจะขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณกำลังทำงาน:

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

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

• หากคุณต้องการใช้ AOP สำหรับข้อกังวลข้ามบางอย่างIoC จะให้ hooksเพื่อสกัดกั้นการเรียกใช้เมธอด สิ่งนี้ทำกันน้อยกว่าในโครงการ แต่ IoC ทำให้ง่ายขึ้น

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

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

ฉันใช้คอนเทนเนอร์ IoC และชื่นชมการทำงาน แต่ต้องยอมรับว่าฉันสังเกตเห็นการแลกเปลี่ยน: รหัสของฉันชัดเจนมากขึ้นในระดับชั้นเรียนและชัดเจนน้อยกว่าในระดับแอปพลิเคชัน (เช่นการควบคุมการแสดงภาพ)

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

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

ทำไมไม่ทำเช่นนี้โดยปราศจากเวทมนต์แบบคงที่:

interface IServiceA { }
interface IServiceB { }
class ServiceA : IServiceA { }
class ServiceB : IServiceB { }

class StubServiceA : IServiceA { }
class StubServiceB : IServiceB { }

interface IRoot { IMiddle Middle { get; set; } }
interface IMiddle { ILeaf Leaf { get; set; } }
interface ILeaf { }

class Root : IRoot
{
    public IMiddle Middle { get; set; }

    public Root(IMiddle middle)
    {
        Middle = middle;
    }

}

class Middle : IMiddle
{
    public ILeaf Leaf { get; set; }

    public Middle(ILeaf leaf)
    {
        Leaf = leaf;
    }
}

class Leaf : ILeaf
{
    IServiceA ServiceA { get; set; }
    IServiceB ServiceB { get; set; }

    public Leaf(IServiceA serviceA, IServiceB serviceB)
    {
        ServiceA = serviceA;
        ServiceB = serviceB;
    }
}


interface IApplicationFactory
{
    IRoot CreateRoot();
}

abstract class ApplicationAbstractFactory : IApplicationFactory
{
    protected abstract IServiceA ServiceA { get; }
    protected abstract IServiceB ServiceB { get; }

    protected IMiddle CreateMiddle()
    {
        return new Middle(CreateLeaf());
    }

    protected ILeaf CreateLeaf()
    {
        return new Leaf(ServiceA,ServiceB);
    }


    public IRoot CreateRoot()
    {
        return new Root(CreateMiddle());
    }
}

class ProductionApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new ServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new ServiceB(); }
    }
}

class FunctionalTestsApplication : ApplicationAbstractFactory
{
    protected override IServiceA ServiceA
    {
        get { return new StubServiceA(); }
    }

    protected override IServiceB ServiceB
    {
        get { return new StubServiceB(); }
    }
}


namespace ConsoleApplication5
{
    class Program
    {
        static void Main(string[] args)
        {
            var factory = new ProductionApplication();
            var root = factory.CreateRoot();

        }
    }

    //[TestFixture]
    class FunctionalTests
    {
        //[Test]
        public void Test()
        {
            var factory = new FunctionalTestsApplication();
            var root = factory.CreateRoot();
        }
    }
}

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

ข้อดี:

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

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

ประโยชน์ที่ใหญ่ที่สุดของการใช้คอนเทนเนอร์ IoC สำหรับฉัน (โดยส่วนตัวแล้วฉันใช้ Ninject) คือการกำจัดการตั้งค่าและวัตถุสถานะทั่วโลกประเภทอื่น ๆ

ฉันไม่ได้เขียนโปรแกรมสำหรับเว็บของฉัน Mine เป็นแอปพลิเคชั่นคอนโซลและในหลาย ๆ ที่ที่ต้นไม้ฉันต้องการเข้าถึงการตั้งค่าหรือข้อมูลเมตาที่ระบุโดยผู้ใช้ที่สร้างขึ้นในสาขาต้นไม้แยกต่างหาก ด้วย IoC ฉันเพียงแค่บอก Ninject ให้ถือว่าการตั้งค่าเป็นแบบซิงเกิล (เพราะมีเพียงหนึ่งตัวอย่างเท่านั้น) ขอการตั้งค่าหรือพจนานุกรมใน Constructor และ Presto ... พวกมันจะปรากฏขึ้นเมื่อฉันต้องการมัน!

หากไม่มีการใช้คอนเทนเนอร์ IoC ฉันจะต้องผ่านการตั้งค่าและ / หรือข้อมูลเมตาลงไปจนถึงวัตถุ 2, 3, ... , n ก่อนที่วัตถุนั้นจะต้องการใช้จริง

มีประโยชน์อื่น ๆ อีกมากมายสำหรับ DI / IoC container เนื่องจากคนอื่น ๆ มีรายละเอียดที่นี่และการย้ายจากความคิดในการสร้างวัตถุไปยังวัตถุที่ร้องขออาจทำให้จิตใจไม่สบายใจ แต่การใช้ DI นั้นมีประโยชน์มากสำหรับฉันและทีมของฉัน คลังแสงของคุณ!

กรอบ IoC นั้นยอดเยี่ยมหากคุณต้องการ ...

• ... ทิ้งความปลอดภัยประเภท เฟรมเวิร์ก IoC จำนวนมาก (ทั้งหมด?) บังคับให้คุณเรียกใช้รหัสหากคุณต้องการแน่ใจว่าทุกสิ่งถูกเชื่อมโยงอย่างถูกต้อง "เฮ้! หวังว่าฉันจะตั้งค่าทุกอย่างแล้วดังนั้นการเริ่มต้นของ 100 คลาสเหล่านี้จะไม่ล้มเหลวในการผลิตโดยโยนข้อยกเว้น null-pointer!"

• ... ทิ้งรหัสของคุณด้วย globals (กรอบ IoC ทั้งหมดเกี่ยวกับการเปลี่ยนสถานะทั่วโลก)

• ... เขียนโค้ดเส็งเคร็งที่มีการอ้างอิงที่ไม่ชัดเจนซึ่งยากต่อการปรับโครงสร้างเนื่องจากคุณจะไม่มีทางรู้ว่าขึ้นอยู่กับอะไร

ปัญหาของ IoC คือคนที่ใช้พวกมันเคยเขียนโค้ดแบบนี้

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

ซึ่งเห็นได้ชัดว่ามีข้อบกพร่องเนื่องจากการพึ่งพาระหว่าง Foo และ Bar นั้นมีสายแบบแข็ง จากนั้นพวกเขาก็ตระหนักว่าการเขียนโค้ดเช่นนั้นจะเป็นการดีกว่า

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

ซึ่งก็มีข้อบกพร่องเช่นกัน แต่ก็เห็นได้ชัดน้อยกว่าเช่นกัน ใน Haskell ประเภทของFoo()จะเป็นIO Fooแต่คุณไม่ต้องการIOส่วน - และควรเป็นสัญญาณเตือนว่ามีบางอย่างผิดปกติกับการออกแบบของคุณถ้าคุณได้รับมัน

ในการกำจัดมัน (ส่วนของ IO) รับประโยชน์ทั้งหมดของ IoC-frameworks และไม่มีข้อเสียใด ๆ ที่คุณสามารถใช้โรงงานที่เป็นนามธรรมแทน

ทางออกที่ถูกต้องน่าจะเป็นอะไรที่คล้าย ๆ

data Foo = Foo { apa :: Bar }

หรืออาจจะ

data Foo = forall b. (IBar b) => Foo { apa :: b }

และฉีด (แต่ฉันจะไม่เรียกมันว่าฉีด) บาร์

นอกจากนี้: ดูวิดีโอนี้กับ Erik Meijer (นักประดิษฐ์ของ LINQ) ซึ่งเขาบอกว่า DI สำหรับคนที่ไม่รู้จักคณิตศาสตร์ (และฉันไม่เห็นด้วยมาก): http://www.youtube.com/watch?v = 8Mttjyf-8P4

แตกต่างจากนาย Spolsky ฉันไม่เชื่อว่าคนที่ใช้ IoC-frameworks นั้นฉลาดมาก - ฉันเชื่อว่าพวกเขาไม่รู้คณิตศาสตร์

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

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

var merger = new SimpleWorkflowInstanceMerger(
    new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
    new WorkflowAnswerRowUtil(
        new WorkflowFieldAnswerEntMapper(),
        new ActivityFormFieldDisplayInfoEntMapper(),
        new FieldEntMapper()),
    new AnswerRowMergeInfoRepository());

ในการหวนกลับมันจะเร็วกว่าที่จะใช้เฟรมเวิร์ก IoC เนื่องจากโมดูลกำหนดสิ่งเหล่านี้ทั้งหมดโดยการประชุม

หลังจากใช้เวลาศึกษาคำตอบและความคิดเห็นเกี่ยวกับคำถามนี้ฉันเชื่อว่าคนที่ไม่เห็นด้วยกับการใช้คอนเทนเนอร์ IoC ไม่ได้ฝึกการฉีดขึ้นต่อกันอย่างแท้จริง ตัวอย่างที่ฉันเห็นเป็นแนวทางปฏิบัติที่มักสับสนกับการฉีดพึ่งพา บางคนบ่นเกี่ยวกับความยากลำบากในการ "อ่าน" รหัส หากทำอย่างถูกต้องส่วนใหญ่ของรหัสของคุณควรเหมือนกันเมื่อใช้ DI ด้วยมือเช่นเดียวกับเมื่อใช้คอนเทนเนอร์ IoC ความแตกต่างควรอยู่ใน "จุดเริ่มต้น" ทั้งหมดภายในแอปพลิเคชัน

กล่าวอีกนัยหนึ่งถ้าคุณไม่ชอบคอนเทนเนอร์ IoC คุณอาจไม่ได้ขึ้นอยู่กับวิธีการฉีด Dependency ที่ควรจะทำ

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

public class MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController()
    {
        _simpleMerger = new SimpleWorkflowInstanceMerger(
            new BitFactoryLog(typeof(SimpleWorkflowInstanceMerger).FullName), 
            new WorkflowAnswerRowUtil(
                new WorkflowFieldAnswerEntMapper(),
                new ActivityFormFieldDisplayInfoEntMapper(),
                new FieldEntMapper()),
            new AnswerRowMergeInfoRepository())
    }
    ...
}

ตอนนี้เปรียบเทียบกับการอนุญาตให้กรอบ DI ทำเพื่อคุณ:

public MyController : Controller
{
    private readonly ISimpleWorkflowInstanceMerger _simpleMerger;
    public MyController(ISimpleWorkflowInstanceMerger simpleMerger)
    {
        _simpleMerger = simpleMerger;
    }
    ...
}

ใช้กรอบ DI โปรดทราบว่า:

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

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

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

ปัญหาคือคุณต้องสร้างวัตถุบางแห่ง รูปแบบจากโรงงานเป็นวิธีหนึ่งในการเลื่อนการเชื่อมต่อออกจาก POXO ของคุณ (แบบเก่าธรรมดา "แทรกภาษา OO ของคุณที่นี่" วัตถุ) หากคุณและเพื่อนร่วมงานของคุณล้วนเขียนโค้ดในลักษณะนี้ดังนั้นคอนเทนเนอร์ IoC คือ "การปรับปรุงเพิ่มเติม" ครั้งต่อไปที่คุณสามารถทำกับฐานข้อมูลโค้ดของคุณ มันจะเปลี่ยนรหัสหม้อไอน้ำที่น่ารังเกียจทั้งหมดออกจากวัตถุที่สะอาดและตรรกะทางธุรกิจของคุณ พวกเขาจะได้รับมันและรักมัน เฮคให้ บริษัท พูดคุยเกี่ยวกับสาเหตุที่คุณรักและทำให้ทุกคนกระตือรือร้น

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

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

คุณไม่ต้องการคอนเทนเนอร์ IoC

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

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

ฉันเพิ่งเกิดขึ้นที่จะอยู่ในขั้นตอนของการดึงรหัสออก DI ที่ปลูกในบ้านและแทนที่ด้วย IOC ฉันอาจลบโค้ดกว่า 200 บรรทัดและแทนที่ด้วยประมาณ 10 ใช่ฉันต้องเรียนรู้เล็กน้อยเกี่ยวกับวิธีใช้คอนเทนเนอร์ (Winsor) แต่ฉันเป็นวิศวกรที่ทำงานกับเทคโนโลยีอินเทอร์เน็ตใน ศตวรรษที่ 21 ดังนั้นฉันจึงคุ้นเคยกับสิ่งนั้น ฉันอาจใช้เวลาประมาณ 20 นาทีเพื่อดูวิธีการ นี่คุ้มค่ากับเวลาของฉัน

ในขณะที่คุณยังคงแยกชั้นเรียนของคุณและคว่ำการอ้างอิงของคุณชั้นเรียนยังคงมีขนาดเล็กและ "กราฟการพึ่งพา" ยังคงมีขนาดใหญ่ขึ้นเรื่อย ๆ (สิ่งนี้ไม่ได้เลวร้าย) การใช้คุณสมบัติพื้นฐานของคอนเทนเนอร์ IoC ทำให้การเชื่อมต่อวัตถุเหล่านี้เป็นเรื่องเล็กน้อย แต่การทำด้วยตนเองอาจทำให้เกิดภาระได้มาก ตัวอย่างเช่นถ้าฉันต้องการสร้างตัวอย่างใหม่ของ "Foo" แต่ต้องการ "Bar" และ "บาร์" ต้องการ "A", "B" และ "C" และแต่ละคนต้องการสิ่งอื่น ๆ 3 อย่าง ฯลฯ ฯลฯ (ใช่ฉันไม่สามารถหาชื่อปลอมที่ดีได้ :))

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

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

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

มันไม่เคยทำให้ฉันประหลาดใจเมื่อคนเริ่มพ่นออกมาเกี่ยวกับความสะอาดของรหัส IoC ที่เป็นกลุ่มคนที่ครั้งหนึ่งเคยพูดกันว่าเทมเพลตใน C ++ นั้นเป็นวิธีที่สง่างามที่จะย้อนกลับไปในยุค 90 แต่ทุกวันนี้ . เฮีย!

ใน. NET world AOP นั้นไม่ได้รับความนิยมมากนักดังนั้นสำหรับ DI Framework นั้นเป็นทางเลือกเดียวที่แท้จริงของคุณไม่ว่าคุณจะเขียนด้วยตนเองหรือใช้เฟรมเวิร์กอื่น

หากคุณใช้ AOP คุณสามารถฉีดเมื่อคุณคอมไพล์แอปพลิเคชันของคุณซึ่งพบได้ทั่วไปใน Java

มีประโยชน์มากมายสำหรับ DI เช่นการมีเพศสัมพันธ์ที่ลดลงดังนั้นการทดสอบหน่วยจะง่ายขึ้น แต่คุณจะนำไปใช้อย่างไร คุณต้องการใช้การสะท้อนเพื่อทำเอง

เกือบ 3 ปีแล้วใช่มั้ย

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

2. หากเราใช้ Java Spring framework ที่ได้รับความนิยมมากที่สุดการกำหนดค่า IoC จะถูกย้ายจาก XMl ไปเป็นรหัสและตอนนี้ก็จะเป็นเช่นนี้

`@Configuration คลาสสาธารณะ AppConfig {

public @Bean TransferService transferService() {
    return new TransferServiceImpl(accountRepository());
}

public @Bean AccountRepository accountRepository() {
    return new InMemoryAccountRepository();
}

} `และเราจำเป็นต้องมีกรอบในการทำเช่นนี้ทำไม?

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

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

ถ้าใช่คุณอาจต้องการคอนเทนเนอร์ IoC ถ้าไม่เช่นนั้นคุณเพียงแค่ย้ายการเริ่มต้นออกจากที่นักพัฒนาสามารถดูได้ง่าย

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

ฉันเชื่อว่าสำหรับการใช้งานส่วนใหญ่บอกว่า IoC Containers ลบรหัสที่ไม่จำเป็นเป็นตำนาน

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

ใครมีความคิดเห็นเกี่ยวกับเรื่องนี้?

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

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

เพียงเพื่อให้ชัดเจนข้อดีที่ฉันเห็นพวกเขา: 1) งบใหม่ทั้งหมด ในที่เดียวที่ root ของรหัส 2) โค้ดตัวคูณใหม่ทั้งหมดพร้อมการเปลี่ยนแปลงเพียงครั้งเดียว 3) คะแนนพิเศษสำหรับ 'cool factor' 'เพราะมันคือ ... เอ่อ: เจ๋ง : p

ฉันจะพยายามค้นหาว่าทำไม IOC อาจไม่ดีสำหรับจากมุมมองของฉัน

เช่นเดียวกับทุกสิ่งทุกอย่าง IOC container (หรือ Einstein จะใส่ I = OC ^ 2) เป็นแนวคิดที่คุณต้องตัดสินใจด้วยตัวเองหากคุณต้องการหรือไม่อยู่ในรหัสของคุณ แฟชั่นล่าสุดโวยวายเกี่ยวกับ IOC เป็นเพียงแฟชั่น อย่าตกหลุมรักแฟชั่นนั่นเป็นครั้งแรก มีแนวคิดมากมายที่คุณสามารถนำไปใช้ในโค้ดของคุณได้ ก่อนอื่นฉันใช้การฉีดแบบพึ่งพาตั้งแต่ฉันเริ่มเขียนโปรแกรมและเรียนรู้คำศัพท์นั้นเมื่อมันได้รับความนิยมภายใต้ชื่อนั้น การควบคุมการพึ่งพาเป็นเรื่องที่เก่าแก่มากและได้รับการแก้ไขแล้วในหลายล้านล้านวิธีขึ้นอยู่กับสิ่งที่แยกจากสิ่งที่ Decoupling ทุกอย่างจากทุกสิ่งเป็นเรื่องไร้สาระ ปัญหาของคอนเทนเนอร์ IOC คือพยายามใช้ประโยชน์จาก Entity Framework หรือ NHibernate ในขณะที่เขียน mapper เชิงสัมพันธ์เชิงวัตถุเป็นสิ่งที่จำเป็นทันทีที่คุณต้องเชื่อมโยงฐานข้อมูลใด ๆ กับระบบของคุณคอนเทนเนอร์ IOC นั้นไม่จำเป็นเสมอไป ดังนั้นเมื่อคอนเทนเนอร์ IOC มีประโยชน์:

1. เมื่อคุณมีสถานการณ์ที่มีการพึ่งพาจำนวนมากที่คุณต้องการจัดระเบียบ
2. เมื่อคุณไม่สนใจเกี่ยวกับรหัสของคุณกับผลิตภัณฑ์ของบุคคลที่สาม
3. เมื่อนักพัฒนาของคุณต้องการเรียนรู้วิธีการทำงานกับเครื่องมือใหม่

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

2: การรวมรหัสของคุณกับรหัสบุคคลที่สามเป็นปัญหา HuGe ฉันทำงานกับรหัสที่มีอายุ 10 ปีขึ้นไปและตามมาในเวลานั้นแนวคิดที่ล้ำสมัยและ ATL, COM, COM + และอื่น ๆ ไม่มีอะไรที่คุณสามารถทำได้กับรหัสนั้นในตอนนี้ สิ่งที่ฉันกำลังพูดคือแนวคิดขั้นสูงให้ประโยชน์ที่ชัดเจน แต่สิ่งนี้ถูกยกเลิกในระยะยาวด้วยความได้เปรียบที่ล้าสมัยเอง มันทำให้ราคาแพงขึ้นทั้งหมด

3: การพัฒนาซอฟต์แวร์นั้นยากพอ คุณสามารถขยายให้อยู่ในระดับที่ไม่สามารถจดจำได้หากคุณอนุญาตให้แนวคิดขั้นสูงสามารถครอบตัดโค้ดของคุณ มีปัญหากับ IOC2 แม้ว่ามันจะเป็นการแยกการพึ่งพามัน แต่ก็เป็นการแยกการไหลของลอจิกเช่นกัน ลองนึกภาพคุณพบข้อผิดพลาดและคุณต้องหยุดพักเพื่อตรวจสอบสถานการณ์ IOC2 เป็นแนวคิดขั้นสูงอื่น ๆ ทำให้ยากขึ้น การแก้ไขจุดบกพร่องภายในแนวคิดนั้นยากกว่าการแก้ไขจุดบกพร่องในรหัสตัววางเพราะเมื่อคุณแก้ไขจุดบกพร่องแนวคิดจะต้องได้รับการปฏิบัติตามอีกครั้ง (เพื่อให้ตัวอย่างแก่คุณ C ++ .NET เปลี่ยนแปลงไวยากรณ์อย่างต่อเนื่องจนคุณต้องคิดให้หนักก่อนที่จะทำการปรับเปลี่ยน. NET รุ่นเก่าบางรุ่น) ดังนั้นปัญหากับ IOC คืออะไร ปัญหาอยู่ในการแก้ไขการอ้างอิง ตรรกะในการแก้ไขนั้นมักถูกซ่อนอยู่ใน IOC2 อาจเขียนในลักษณะแปลกที่คุณต้องเรียนรู้และบำรุงรักษา ผลิตภัณฑ์บุคคลที่สามของคุณจะมีใน 5 ปีหรือไม่ ไมโครซอฟท์ไม่ได้

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

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

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

โดยส่วนตัวแล้วฉันใช้ IoC เป็นโครงสร้างแผนที่บางส่วนของแอปพลิเคชันของฉัน (ใช่ฉันยังชอบ StructureMap;)) มันทำให้ง่ายต่อการแทนที่การใช้งานอินเตอร์เฟสของฉันด้วยการใช้งาน Moq ระหว่างการทดสอบ การสร้างการตั้งค่าการทดสอบสามารถทำได้ง่ายเหมือนกับการเริ่มต้นการโทรใหม่ไปยัง IoC-framework ของฉันโดยการแทนที่คลาสใดก็ตามที่เป็นขอบเขตการทดสอบของฉันด้วยการจำลอง

นี่อาจไม่ใช่สิ่งที่ IoC มีเพื่อ แต่เป็นสิ่งที่ฉันพบว่าตัวเองใช้มันเพื่อประโยชน์สูงสุด ..

IOC ภาชนะบรรจุแก้ไขปัญหาที่คุณอาจไม่ได้ แต่มันเป็นปัญหาที่ดีที่จะมี

http://kozmic.net/2012/10/23/ioc-container-solves-a-problem-you-might-not-have-but-its-a-nice-problem-to-have/

คุณไม่จำเป็นต้องมีกรอบการทำงานเพื่อให้เกิดการฉีดพึ่งพา คุณสามารถทำได้โดยใช้แนวคิดหลักของจาวาเช่นกัน http://en.wikipedia.org/wiki/Dependency_injection#Code_illustration_using_Java

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

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

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

2) คอนเทนเนอร์ IoC ในความคิดของฉันเป็นรูปแบบของ "การเขียนโปรแกรมกล่องดำ" ฉันได้พบว่าโดยเฉพาะอย่างยิ่งนักพัฒนาที่มีประสบการณ์น้อยของเรามักจะละเมิดพวกเขา มันช่วยให้โปรแกรมเมอร์ไม่ต้องคิดเกี่ยวกับว่าวัตถุควรสัมพันธ์กันหรือแยกมันอย่างไรเพราะมันมีกลไกที่ทำให้พวกเขาสามารถหยิบวัตถุใด ๆ ที่พวกเขาต้องการออกมาจากอากาศ เช่นอาจมีเหตุผลในการออกแบบที่ดีที่ ObjectA ไม่ควรรู้เกี่ยวกับ ObjectB โดยตรง แต่แทนที่จะสร้างโรงงานหรือบริดจ์หรือ locator Service โปรแกรมเมอร์ที่ไม่มีประสบการณ์จะพูดว่า "ไม่มีปัญหาฉันแค่หยิบ ObjectB จากคอนเทนเนอร์ IoC " สิ่งนี้สามารถนำไปสู่การมีวัตถุร่วมเพิ่มขึ้นซึ่งเป็นสิ่งที่ IoC ควรจะช่วยป้องกัน

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