Unity 3：微软的依赖注入容器详解

需积分: 35 131 浏览量更新于2024-07-23 收藏 3.3MB PDF 举报

"Unity Application Block (Unity 3) - 微软的依赖注入容器技术" 《Unity Application Block (Unity 3)》是微软提供的一种实用技术，它属于微软实践与模式系列，旨在解决.NET开发中的依赖注入问题。Unity是微软阵营中一个强大的依赖注入(Dependency Injection, DI)容器，允许开发者在应用程序中解耦组件，提高代码的可测试性和可维护性，避免硬编码依赖关系。依赖注入是一种设计模式，它使对象能够在其运行时接收依赖项，而不是在创建时就直接绑定。这样做的好处是增强了灵活性，因为组件可以更容易地替换或配置，而无需更改代码。Unity作为一个DI容器，提供了许多高级特性，如类型注册、生命周期管理、拦截器支持和策略注入等。本书由Dominic Betts、Grigori Melnik、Fernando Simonazzi和Mani Subramanian合著，并由Chris Tavares作序，深入介绍了如何使用Unity进行依赖注入。书中可能涵盖了以下关键知识点： 1. **Unity基本概念**：介绍Unity容器的基本使用方法，包括如何创建容器实例，以及如何通过容器解析依赖关系。 2. **类型注册**：讲解如何注册类型到Unity容器中，包括接口到实现类的映射，以及多个实现类的多态注册。 3. **依赖注入模式**：介绍构造函数注入、属性注入和方法注入等不同方式，以及它们在不同场景下的适用性。 4. **生命周期管理**：讨论对象的生命周期策略，例如单例、瞬时和容器控制的生命周期，以及如何自定义生命周期管理。 5. **拦截器和AOP（面向切面编程）**：解释如何利用Unity实现拦截器，用于执行如日志记录、事务处理等跨切面的逻辑。 6. **扩展性**：介绍如何通过Unity的扩展点来定制容器行为，比如自定义解析策略和注册行为。 7. **策略注入**：说明如何在运行时动态改变组件的行为，通过策略注入实现灵活的配置。 8. **测试和调试**：探讨使用Unity提升组件测试效率的方法，以及如何在调试过程中利用Unity的特性。 9. **实战示例**：提供实际项目中的应用示例，帮助读者更好地理解和应用Unity。 10. **最佳实践**：分享关于使用Unity的最佳实践和注意事项，以避免常见的陷阱和错误。这本书适合对.NET框架有一定了解，希望深入学习依赖注入和微服务架构的开发者。无论是初学者还是有经验的开发人员，都可以从中受益，提升软件设计的灵活性和质量。



Before you learn about dependency injection and Unity, you need to understand

why you should use them. And in order to understand why you should use them,

you should understand what types of problems dependency injection and Unity

are designed to help you address. This introductory chapter will not say much

about Unity, or indeed say much about dependency injection, but it will provide

some necessary background information that will help you to appreciate the

beneﬁts of dependency injection as a technique and why Unity does things the

way it does.

The next chapter, Chapter 2, “Dependency Injection,” will show you how depen-

dency injection can help you meet the requirements outlined in this chapter, and the

following chapter, Chapter 3, “Dependency Injection with Unity,” shows how Unity

helps you to implement the dependency injection approach in your applications.

Motivations

When you design and develop software systems, there are many requirements

to take into account. Some will be speciﬁc to the system in question and some

will be more general in purpose. You can categorize some requirements as func-

tional requirements, and some as non-functional requirements (or quality attri-

butes). The full set of requirements will vary for every different system. The set

of requirements outlined below are common requirements, especially for line-

of-business (LOB) software systems with relatively long anticipated lifetimes.

They are not all necessarily going to be important for every system you develop,

but you can be sure that some of them will be on the list of requirements for

many of the projects you work on.

Maintainability

As systems become larger, and as the expected lifetimes of systems get longer,

maintaining those systems becomes more and more of a challenge. Very often, the

original team members who developed the system are no longer available, or no

longer remember the details of the system. Documentation may be out of date or

even lost. At the same time, the business may be demanding swift action to meet

some pressing new business need. Maintainability is the quality of a software

system that determines how easily and how efﬁciently you can update it. You may

need to update a system if a defect is discovered that must be ﬁxed (in other

words, performing corrective maintenance), if some change in the operating envi-

ronment requires you to make a change in the system, or if you need to add new

features to the system to meet a business requirement (perfective maintenance).

Maintainable systems enhance the agility of the organization and reduce costs.

1 Introduction

It is very hard to make

existing systems more

maintainable. It is much

better to design for

maintainability from the very

start.

This chapter introduces

a lot of requirements and

principles. Don’t assume

that they are all relevant all

of the time. However, most

enterprise systems have

some of the requirements,

and the principles all point

towards good design and

coding practices.

  

Therefore, you should include maintainability as one of your design goals, along

with others such as reliability, security, and scalability.

Testability

A testable system is one that enables you to effectively test individual parts of

the system. Designing and writing effective tests can be just as challenging as

designing and writing testable application code, especially as systems become

larger and more complex. Methodologies such as test-driven development (TDD)

require you to write a unit test before writing any code to implement a new

feature and the goal of such a design technique is to improve the quality of your

application. Such design techniques also help to extend the coverage of your unit

tests, reduce the likelihood of regressions, and make refactoring easier. However,

as part of your testing processes you should also incorporate other types of tests

such as acceptance tests, integration tests, performance tests, and stress tests.

Running tests can also cost money and be time consuming because of the re-

quirement to test in a realistic environment. For example, for some types of

testing on a cloud-based application you need to deploy the application to the

cloud environment and run the tests in the cloud. If you use TDD, it may be

impractical to run all the tests in the cloud all of the time because of the time it

takes to deploy your application, even to a local emulator. In this type of sce-

nario, you may decide to use test doubles (simple stubs or veriﬁable mocks) that

replace the real components in the cloud environment with test implementa-

tions in order to enable you to run your suite of unit tests in isolation during the

standard TDD development cycle.

Testability should be another of the design goals for your system along with

maintainability and agility: a testable system is typically more maintainable, and

vice versa.

Flexibility and Extensibility

Flexibility and extensibility are also often on the list of desirable attributes of

enterprise applications. Given that business requirements often change, both

during the development of an application and after it is running in production,

you should try to design the application to make it ﬂexible so that it can be

adapted to work in different ways and extensible so that you can add new fea-

tures. For example, you may need to convert your application from running

on-premises to running in the cloud.

Late Binding

In some application scenarios, you may have a requirement to support late bind-

ing. Late binding is useful if you require the ability to replace part of your system

without recompiling. For example, your application might support multiple re-

lational databases with a separate module for each supported database type.

You can use declarative conﬁguration to tell the application to use a speciﬁc

module at runtime. Another scenario where late binding can be useful is to en-

able users of the system to provide their own customization through a plug-in.

Again, you can instruct the system to use a speciﬁc customization by using a

conﬁguration setting or a convention where the system scans a particular loca-

tion on the ﬁle system for modules to use.

For a great discussion on the

use of test doubles, see the

point/counterpoint debate

by Steve Freeman, Nat Pryce

and Joshua Kerievsky in IEEE

Software (Volume: 24, Issue:

3), May/June 2007, pp.80-83.

Not all systems have a

requirement for late binding.

It is typically required to

support a speciﬁc feature

of the application such as

customization using a plug-

in architecture.

Using test doubles is a

great way to ensure that

you can continuously run

your unit tests during the

development process.

However, you must still fully

test your application in a real

environment.



I

Parallel Development

When you are developing large scale (or even small and medium scale) systems,

it is not practical to have the entire development team working simultaneously

on the same feature or component. In reality, you will assign different features

and components to smaller groups to work on in parallel. Although this ap-

proach enables you to reduce the overall duration of the project, it does intro-

duce additional complexities: you need to manage multiple groups and to ensure

that you can integrate the parts of the application developed by different groups

to work correctly together.

Crosscutting Concerns

Enterprise applications typically need to address a range of crosscutting concerns

such as validation, exception handling, and logging. You may need these features

in many different areas of the application and you will want to implement them

in a standard, consistent way to improve the maintainability of the system. Ide-

ally, you want a mechanism that will enable you to efﬁciently and transparently

add behaviors to your objects at either design time or run time without requiring

you make changes to your existing classes. Often, you need the ability to con-

ﬁgure these features at runtime and in some cases, add features to address a new

crosscutting concern to an existing application.

Loose Coupling

You can address many of the requirements listed in the previous sections by

ensuring that your design results in an application that loosely couples the many

parts that make up the application. Loose coupling, as opposed to tight coupling,

means reducing the number of dependencies between the components that

make up your system. This makes it easier and safer to make changes in one area

of the system because each part of the system is largely independent of the

other.

A S E

The following example illustrates tight coupling where the Management-

Controller class depends directly on the TenantStore class. These classes might

be in different Visual Studio projects.

public class TenantStore

{

...

public Tenant GetTenant(string tenant)

{

...

}

public IEnumerable<string> GetTenantNames()

{

...

}

Loose coupling should be a

general design goal for your

enterprise applications.

It can be a signiﬁcant

challenge to ensure that

classes and components

developed independently do

work together.

For a large enterprise

system, it’s important to be

able to manage crosscutting

concerns such as logging and

validation in a consistent

manner. I often need to

change the logging level

on a speciﬁc component at

run time to troubleshoot an

issue without restarting the

system.

  

public class ManagementController

{

private readonly TenantStore tenantStore;

public ManagementController()

{

tenantStore = new TenantStore(...);

}

public ActionResult Index()

{

var model = new TenantPageViewData<IEnumerable<string>>

(this.tenantStore.GetTenantNames())

{

Title = "Subscribers"

};

return this.View(model);

}

public ActionResult Detail(string tenant)

{

var contentModel = this.tenantStore.GetTenant(tenant);

var model = new TenantPageViewData<Tenant>(contentModel)

{

Title = string.Format("{0} details", contentModel.Name)

};

return this.View(model);

}

...

}

The ManagementController and TenantStore classes are used in various forms throughout this guide.

Although the ManagementController class is an ASP.NET MVC controller, you don’t need to know about

MVC to follow along. However, these examples are intended to look like the kinds of classes you would

encounter in a real-world system, especially the examples in Chapter 3.

In this example, the TenantStore class implements a repository that handles access to an underlying data store

such as a relational database, and the ManagementController is an MVC controller class that requests data

from the repository. Note that the ManagementController class must either instantiate a TenantStore object

or obtain a reference to a TenantStore object from somewhere else before it can invoke the GetTenant and

GetTenantNames methods. The ManagementController class depends on the speciﬁc, concrete TenantStore

class.

If you refer back to the list of common desirable requirements for enterprise applications at the start of this

chapter, you can evaluate how well the approach outlined in the previous code sample helps you to meet them.

•

Although this simple example shows only a single client class of the TenantStore class, in practice there

may be many client classes in your application that use the TenantStore class. If you assume that each

client class is responsible for instantiating or locating a TenantStore object at runtime, then all of those

classes are tied to a particular constructor or initialization method in that TenantStore class, and may all

need to be changed if the implementation of the TenantStore class changes. This potentially makes

maintenance of the TenantStore class more complex, more error prone, and more time consuming.

剩余141页未读，继续阅读

Yangyanfeng2

粉丝: 0
资源: 3

Unity 3：微软的依赖注入容器详解

Unity Application Block 1.2 参考文档

Unity Application Block 1.2

ASP.NET Mvc + NHibernate + Unity Application Block 示例程序

C# Game Programming Cookbook for Unity 3D - 2014

[EntLib]微软企业库5 0 学习之路 第十步 使用Unity解耦你的系统 PART4 Unity&PIAB

Nginx部署使用gzip压缩的Unity网页WebGL

EnterpriseLibrary系列课程1概述第3集

Unity与PIAB整合实现实现系统解耦

Unity Pro 2.0.2 PLC调试助手：应用诊断与系统指南

YOLOv8 Application Guide in Game Development: Object Recognition Technology in Virtual Worlds

最新资源

[EntLib]微软企业库5 0 学习之路第十步使用Unity解耦你的系统 PART4 Unity&PIAB