DI / IoC container vs các nhà máy: Tôi định cấu hình ứng dụng của mình ở đâu và tại sao?

Tôi đang cố gắng tìm ra khi nào nên sử dụng sổ đăng ký DIC / IoC để định cấu hình phần mềm của mình và khi nào nên sử dụng các nhà máy, cùng với lý do đằng sau một trong hai cách tiếp cận.

Tôi đang sử dụng StructMap làm thùng chứa DI (DIC), dễ dàng cấu hình bằng cách sử dụng đăng ký. Trong DIC thực tế, tất cả các đối tượng đã đăng ký đều tĩnh theo nghĩa, tôi không cần thay đổi / trao đổi bất kỳ triển khai / thể hiện nào trong thời gian chạy, một khi DIC được cấu hình và chúng được cấu hình trong DIC dưới dạng singletons. Tuy nhiên, vì phần mềm của tôi (SW) sẽ chạy trên các thiết bị khác nhau, tôi cần phải chọn một sổ đăng ký dành riêng cho thiết bị tùy thuộc vào thiết bị mà SW của tôi chạy để định cấu hình phần cứng phù hợp.

Do việc xây dựng một số đối tượng của tôi yêu cầu đọc trong các tệp cấu hình, tôi đang sử dụng các nhà máy để trả lại các phiên bản này cho DIC, để tách việc đọc cấu hình khỏi việc tạo đối tượng. Tôi đã đăng ký getters nhà máy trong DIC cho các loại plugin tương ứng.

Bây giờ nói rằng tôi có một loại plugin IMotorvới các loại cụ thể Motor1và Motor2, nên được xử lý bởi một nhà máy. Hiện tại có hai cách tôi có thể quyết định cách định cấu hình thiết bị của mình:

1. Tôi chuyển thông tin về thiết bị mà SW đang chạy tới MotorFactoryvà nó trả về đúng động cơ, Motor1hoặc Motor2. Trong trường hợp này logic để quyết định là bên trong Nhà máy.
2. Tôi định cấu hình DIC theo thiết bị mà nó đang chạy và tạo hai nhà máy Motor1Factoryvà Motor2Factory, nơi một người tạo Motor1và người kia Motor2. Trong trường hợp này, tôi sẽ có các mục đăng ký khác nhau IMotortrong các cơ quan đăng ký dành riêng cho thiết bị sử dụng Motor1Factoryhoặc Motor2Factory.

Bây giờ câu hỏi của tôi là: Một trong hai phương pháp này là thích hợp hơn và tại sao? Đối với tôi, có vẻ như trường hợp đầu tiên không đơn giản và phức tạp, vì tôi đang lan truyền logic quyết định loại nào sẽ khởi tạo trong toàn bộ cơ sở mã. Trong trường hợp thứ hai, tôi nhân số hiệu quả số lượng nhà máy trong mã của mình, vì tôi sẽ cần một nhà máy cho (hầu hết) từng loại bê tông. Nó càng trở nên khó hiểu hơn với tôi, khi các nhà máy trừu tượng được thêm vào hỗn hợp.

Vì vậy, một lần nữa: Khi nào tôi nên sử dụng phương pháp này hay phương pháp khác? Và quan trọng hơn: các chỉ số tốt để quyết định con đường nào để đi?

Nếu bạn sử dụng cả hai tôi sẽ đi cho một cái gì đó đơn giản:

• DI / IoC: cho mọi cấu hình sẽ không thay đổi khi chạy.
• Factory: để tạo phiên bản của các đối tượng trong thời gian chạy phụ thuộc vào các tham số đầu vào thời gian chạy. Các phiên bản của nhà máy được bơm bởi container DI.

Các nhà máy trừu tượng được sử dụng khi bạn có các đối tượng liên quan thông qua hệ thống phân cấp cần thay đổi cùng nhau. Tôi không thấy điều đó ở đây.

Những gì tôi thấy là bạn đang tự hỏi liệu một nhà máy nên chọn động cơ hay DIC nên chọn một nhà máy sản xuất một động cơ cụ thể.

Thật khó để chọn chính xác bởi vì một nhà máy và DIC làm những việc rất giống nhau. Sự khác biệt là nhà máy tập trung vào một vấn đề cụ thể và DIC thì tổng quát hơn.

Câu hỏi này đặt ra: bạn có nhu cầu về mã đặc biệt cho vấn đề này sẽ sống trong nhà máy không? Hoặc là nó chung chung hơn như đọc chi tiết cấu hình từ một tập tin?

Hãy nhớ rằng trong khi bạn chỉ có thể chọn giữa Motor1và Motor2hôm nay, ngày mai có thể có một Motor3. Yêu thích các thiết kế sẽ làm cho Motor3dễ dàng để thêm.

Tôi sẽ tách logic "sử dụng động cơ nào" thành một Nhà máy đặc biệt gọi là Builder (mẫu) và sử dụng IOC-Container cho cả hai động cơ làm chi tiết triển khai của trình xây dựng.

Theo nguyên tắc chung:

• bạn cần một nhà máy (hoặc một người xây dựng) nếu bạn phải tạo nhiều đối tượng động của lớp / giao diện. (tức là với mỗi chiếc xe bạn sản xuất, bạn phải tạo một động cơ mới)
• nếu bạn chỉ cần một phiên bản tĩnh của một lớp, ioc / di có thể thực hiện công việc cho bạn (tức là bạn chỉ cần một phiên bản tĩnh của dịch vụ thanh toán và một phiên bản tĩnh của MotorBuilderService)