使用Unity进行依赖注入实战指南

5星 · 超过95%的资源需积分: 35 65 浏览量更新于2024-07-24 收藏 3.3MB PDF 举报

"Dependency Injection with Unity (Microsoft patterns & practices)" 是一份关于使用Unity实现依赖注入的指南，由微软模式与实践团队编写。该指南详细介绍了如何通过依赖注入来处理复杂软件系统的复杂性，以实现代码的松耦合、可重用性和可维护性。依赖注入（DI）是一种设计模式，它允许消除硬编码的依赖关系，使得服务的组装可以通过轻松更改依赖关系来完成，无论是在运行时还是编译时。这种模式促进了代码的复用，并且使得设计更加灵活，更容易维护。Unity是一个轻量级、可扩展的依赖注入容器，它提供了对象生命周期管理、拦截和约定注册等额外功能。通过Unity，开发者可以更方便地处理应用程序的横切关注点，最大化利用依赖注入和Unity的优势。该指南深入浅出地讲解了各种依赖注入风格，并探讨了如何通过自定义扩展增强Unity。此外，还包含了许多权衡讨论、技巧和提示，以及一个真实世界的应用示例，帮助读者掌握这些技术。Unity适用于桌面应用、Web应用、服务和云应用等多种类型的应用程序，鼓励读者通过实验示例代码来探索更多可能性。 " Tales from the Trenches" 部分收集了来自实际项目开发者的案例研究，从不同角度展示了在各种场景下使用Unity的可能性，强调了其易用性和灵活性。无论您是经验丰富的开发者还是初入开发领域，这份指南都值得您投入时间学习。希望您发现Unity容器能为您的应用带来显著的好处，帮助您实现可维护性、可测试性、灵活性和可扩展性的目标。依赖注入与Unity的结合为构建高质量、易于维护的软件系统提供了一种强大的工具，而这份指南将帮助开发者充分利用这一工具，提升开发效率和软件质量。



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页未读，继续阅读

protorock

粉丝: 2
资源: 5

使用Unity进行依赖注入实战指南

Microsoft.Practices.Unity.dll

Microsoft.Practices.Unity.Configuration.dll

Microsoft.Practices.Unity

.NET Unity IOC框架使用实例详解

Formview Unity和LINQ实现的3层架构

unity：此存储库包含整个软件包的开发环境

Microsoft Prism 4.1

微软Unity IoC框架深度解析

Microsoft Unity 依赖注入开发指南

Unity依赖注入指南：构建松耦合应用

最新资源