Ai đó có thể giải thích về Microsoft Unity?

Question

Tôi đã đọc các bài viết về MSDN về Unity (Dependency Injection, Inversion of Control), nhưng tôi nghĩ rằng tôi cần nó giải thích bằng các thuật ngữ đơn giản (hoặc các ví dụ đơn giản). Tôi đã quen thuộc với mẫu MVPC (chúng tôi sử dụng nó ở đây), nhưng tôi thực sự không thể nắm bắt được điều Unity này, và tôi nghĩ đó là bước tiếp theo trong thiết kế ứng dụng của chúng tôi.

Answer 1

Unity chỉ là một "vùng chứa" IoC. Google StructureMap và dùng thử nó thay thế. Một chút dễ dàng hơn để grok, tôi nghĩ rằng, khi các công cụ IoC là mới cho bạn.

Về cơ bản, nếu bạn hiểu IoC thì bạn hiểu rằng những gì bạn đang làm là đảo ngược sự kiểm soát khi một đối tượng được tạo.

Without IOC:

public class MyClass 
{ 
    IMyService _myService; 

    public MyClass() 
    { 
     _myService = new SomeConcreteService();  
    } 
} 

Với IoC container:

public class MyClass 
{ 
    IMyService _myService; 

    public MyClass(IMyService myService) 
    { 
     _myService = myService;  
    } 
} 

Without IoC, lớp học của bạn dựa trên IMyService phải mới lên một phiên bản cụ thể của dịch vụ để sử dụng. Và đó là điều xấu vì một số lý do (bạn đã kết hợp lớp học của mình với phiên bản cụ thể của IMyService, bạn không thể dễ dàng kiểm tra đơn vị, bạn không thể thay đổi dễ dàng, v.v.)

Với một container IoC bạn "cấu hình" container để giải quyết những phụ thuộc đó cho bạn. Vì vậy, với một chương trình tiêm dựa trên hàm dựng, bạn chỉ cần truyền giao diện cho sự phụ thuộc IMyService vào hàm tạo. Khi bạn tạo MyClass với vùng chứa của mình, vùng chứa của bạn sẽ giải quyết sự phụ thuộc IMyService cho bạn.

Sử dụng StructureMap, cấu hình container trông như thế này: "Khi ai đó yêu cầu các IMyService, cung cấp cho họ một bản sao của SomeConcreteService"

StructureMapConfiguration.ForRequestedType<MyClass>().TheDefaultIsConcreteType<MyClass>(); 
StructureMapConfiguration.ForRequestedType<IMyService>().TheDefaultIsConcreteType<SomeConcreteService>(); 

Vì vậy, những gì bạn đã làm được kể container, Và bạn cũng đã xác định rằng khi ai đó yêu cầu một MyClass, họ sẽ nhận được một MyClass cụ thể.

Đó là tất cả vùng chứa IoC thực sự. Họ có thể làm nhiều hơn, nhưng đó là lực đẩy của nó - họ giải quyết các phụ thuộc cho bạn, vì vậy bạn không phải (và bạn không phải sử dụng từ khóa "mới" trong suốt mã của bạn).

Bước cuối cùng: khi bạn tạo MyClass của bạn, bạn sẽ làm điều này:

var myClass = ObjectFactory.GetInstance<MyClass>(); 

Hy vọng rằng sẽ giúp. Gửi thư điện tử cho tôi bất cứ khi nào bạn muốn.

Answer 2

Unity là một thư viện giống như nhiều thư viện khác cho phép bạn lấy một thể hiện của một loại được yêu cầu mà không phải tự tạo nó. Vì vậy, đưa ra.

public interface ICalculator 
{ 
    void Add(int a, int b); 
} 

public class Calculator : ICalculator 
{ 
    public void Add(int a, int b) 
    { 
     return a + b; 
    } 
} 

Bạn sẽ sử dụng một thư viện như Unity để đăng ký Calculator để được trả lại khi loại ICalculator được yêu cầu aka IoC (Inversion of Control) (ví dụ này là lý thuyết, không đúng kỹ thuật).

IoCLlibrary.Register<ICalculator>.Return<Calculator>(); 

Vì vậy, bây giờ khi bạn muốn một thể hiện của một ICalculator bạn chỉ cần ...

Calculator calc = IoCLibrary.Resolve<ICalculator>(); 

thư viện IoC thường có thể được cấu hình để một trong hai tổ chức một singleton hoặc tạo một đối tượng mới mỗi khi bạn giải quyết một kiểu.

Bây giờ giả sử bạn có một lớp học mà dựa vào một ICalculator có mặt bạn có thể có ..

public class BankingSystem 
{ 
    public BankingSystem(ICalculator calc) 
    { 
     _calc = calc; 
    } 

    private ICalculator _calc; 
} 

Và bạn có thể thiết lập thư viện để tiêm một đối tượng vào constructor khi nó được tạo ra.

Vì vậy, DI hoặc Dependency Injection có nghĩa là tiêm bất kỳ đối tượng nào khác có thể yêu cầu.

Answer 3

Unity là một IoC. Điểm của IoC là trừu tượng sự kết nối của các phụ thuộc giữa các kiểu bên ngoài các kiểu của chúng. Điều này có một vài lợi thế. Trước hết, nó được thực hiện tập trung có nghĩa là bạn không phải thay đổi nhiều mã khi phụ thuộc thay đổi (có thể là trường hợp cho các bài kiểm tra đơn vị).

Hơn nữa, nếu việc kết nối được thực hiện bằng cách sử dụng dữ liệu cấu hình thay vì mã, bạn có thể thực sự rewire các phụ thuộc sau khi triển khai và do đó thay đổi hành vi của ứng dụng mà không thay đổi mã.

Answer 4

Tôi vừa xem chương trình Unity Dependency Injection IoC Screencast 30 phút của David Hayden và cảm thấy đó là một giải thích tốt với các ví dụ. Dưới đây là một đoạn trích từ chương trình ghi chú:

Các hình màn ảnh cho thấy một số tập quán chung của Unity IoC, chẳng hạn như:

• Tạo chủng loại không chứa
• Đăng ký và TypeMappings Giải quyết
• Đăng ký và Giải quyết các kiểu ánh xạ được đặt tên
• Singletons, LifetimeManagers và ContainerControlledLifetimeManager
• Đăng ký các trường hợp hiện tại
• Tiêm Dependencies vào Instances hiện tại
• Populate UnityContainer qua App.config/Web.config
• Xác định Dependencies qua tiêm API như trái ngược với phụ thuộc Thuộc tính
• Sử dụng lồng nhau (Parent-Child) Container

Answer 5

Anh chàng WilcoxTutorials này cho thấy một cuộc biểu tình tuyệt vời của container Unity nhằm vào người mới bắt đầu.

Phần 1: http://www.youtube.com/watch?v=CWwe9Z0Gyew

Phần 2: http://www.youtube.com/watch?v=PsIbevgzQQE

Trong vòng chưa đầy nửa giờ đồng hồ và bạn sẽ hiểu những điều cơ bản!

Answer 6

MSDN có Developer's Guide to Dependency Injection Using Unity có thể hữu ích.

Hướng dẫn dành cho nhà phát triển bắt đầu với các khái niệm cơ bản về việc tiêm phụ thuộc là gì và tiếp tục với các ví dụ về cách sử dụng Unity để tiêm phụ thuộc. Kể từ tháng 2 năm 2014, Hướng dẫn dành cho nhà phát triển bao gồm Unity 3.0, được phát hành vào tháng 4 năm 2013.