Microsoft is named unity of Dependency Injection Application Block

The Microsoft model and Practice team released a dependency injection container called unity or unity Application block. Developers now have the ability to create loosely coupled applications with scalable lightweight containers.

Infoq has the opportunity to interview the Unity Project's development leader, Chris Tavares.

Rob bazinet (RB): Chris, how about yourself and how do you participate in unity?

Chris Tavares (CT): My name is Chris Tavares. I am a senior software developer with the Microsoft Model and practice group. I am currently leading the development of enterprise Library 4 and Unity Application Block. I also wrote most of the unity of the Code, so unity of beauty stems from my "mistakes." I have worked in mode with the practice group for over 2 years. Before I came to work in Microsoft, I started working in industrial software outsourcing, boxed software development, and even some embedded software development since the 90 's.

What is rb:unity Application Block?

Ct:unity is a dependency injection (Dependency Injection,di) container. DI's standard description article comes from Martin Flower[0] "translator Note: Chinese translation see [4]". As a quick summary, the dependency injection container is a tool for building highly loosely coupled software. Depending on the injection container to handle all the details of the interrelated objects, you can build a separate component. This has a significant impact on testability and flexibility.

For example, in a banking system, you can have an object that manages the account transfer. To achieve this goal, you need to obtain a personal account of the object, plus security rules and audit requirements. The usual implementation looks like this:

AccountTransfer
{
TransferMoney( sourceAccountNumber,　destAccountNumber,　amount)
　　{
　　　　Account sourceAccount = AccountDatabase.GetAccount(sourceAccountNumber);
　　　　Account destAccount = AccountDatabase.GetAccount(destAccountNumber);
　　　　sourceAccount.Withdraw(amount);
　　　　destAccount.Deposit(amount);
　　　　Logger.Write(, amount, sourceAccountNumber, destAccountNumber);
　　}
}


It can be imagined that this is pretty scary code (for example, no transaction management), although it can work correctly. ;-)

This is very simple, but it is also highly coupled. Global Accountdatabase class invocation means you can't even compile alone, let alone test. What happens if the account number is from two different banks? Similarly, the global logger means that you must first obtain a logger created by an explicit global logger class before you can use this class. This result is painful when you try to write unit tests, and it also greatly limits flexibility in the long run.

The segregation of duties principle requires that a class not have multiple responsibilities. Here, this class violates this principle, not only about how to transfer the details of the money, but also how to get the account number from the database and how to write the log information. To restore flexibility, these responsibilities need to be separated into different objects and then used by passing back the object to look like this:

AccountTransfer
{
IAccountRepository accounts;
ILogger logger;
AccountTransfer(IAccountRepository accounts, ILogger logger)
　　{
.accounts = accounts;
.logger = logger;
　　}
TransferMoney( sourceAccountNumber,　destAccountNumber,　amount)
　　{
　　　　Account sourceAccount = accounts.GetAccount(sourceAccountNumber);
　　　　Account destAccount = accounts.GetAccount(destAccountNumber);
　　　　sourceAccount.Withdraw(amount);
　　　　destAccount.Deposit(amount);
　　　　logger.Write(, amount, sourceAccountNumber, destAccountNumber);
　　}
}