di

di

Go语言高性能依赖注入框架

DI是一款专注性能的Go语言依赖注入框架,可高效管理应用中对象的生命周期。该框架支持灵活的对象定义、多种检索方式和作用域管理,有效处理复杂依赖关系。DI适用于各类Go程序,尤其适合管理大量对象和依赖的Web应用。它能在需要时创建对象、解析依赖,并在不再使用时妥善关闭,提升开发效率和程序性能。

依赖注入Go语言ContainerBuilderDefinitionGithub开源项目

DI

Dependency injection framework for go programs (golang).

DI handles the life cycle of the objects in your application. It creates them when they are needed, resolves their dependencies, and closes them properly when they are no longer used.

If you do not know if DI could help improve your application, learn more about dependency injection and dependency injection containers:

There is also an Examples section at the end of the documentation.

DI is focused on performance.

Table of contents

go.dev reference Go version GitHub Workflow Status Coverage

Basic usage

A definition contains at least a Build function to create the object.

MyObjectDef := &di.Def{ Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, } // It is possible to add a name or a type to make the definition easier to retrieve. // But it is not mandatory. Check the "Definitions" part of the documentation to learn more about that. MyObjectDef.SetName("my-object") MyObjectDef.SetIs((*MyObject)(nil))

The definition can be added to a builder with the Add method:

builder, err := di.NewEnhancedBuilder() err = builder.Add(MyObjectDef)

Once all the definitions are added to the Builder, you can call the Build method to generate a Container.

ctn, err := builder.Build()

Objects can then be retrieved from the container:

// Either with the definition (recommended) ctn.Get(MyObjectDef).(*MyObject) // Or the name (which is slower) ctn.Get("my-object").(*MyObject) // Or the type (even slower) ctn.Get(reflect.typeOf((*MyObject)(nil))).(*MyObject)

The Get method returns an interface{}. You need to cast the interface before using the object.

The container will only call the definition Build function the first time the Get method is called. After that, the same object is returned (unless the definition has its Unshared field set to true). That means the three calls in the example above return the same pointer. Check the Definitions section to learn more about them.

Builder

EnhancedBuilder usage

You need a builder to create a container.

You should use the EnhancedBuilder. It was introduced to add features that could not be added to the original Builder without breaking backward compatibility.

You need to use the NewEnhancedBuilder function to create the builder. Then you register the definitions with the Add method.

If you add two definitions with the same name, the first one is replaced.

builder, err := di.NewEnhancedBuilder() // Adding a definition named "my-object". err = builder.Add(&di.Def{ Name: "my-object", Build: func(ctn di.Container) (interface{}, error) { return &MyObject{Value: "A"}, nil }, }) // Replacing the definition named "my-object". err = builder.Add(&di.Def{ Name: "my-object", Build: func(ctn di.Container) (interface{}, error) { return &MyObject{Value: "B"}, nil }, }) ctn, err := builder.Build() ctn.Get("my-object").(*MyObject).Value // B

Be sure to handle the errors properly even if it is not the case in this example for conciseness.

EnhancedBuilder limitations

It is only possible to call the EnhancedBuilder.Build function once. After that, it will return an error.

Also, it is not possible to use the same definition in two different EnhancedBuilder.

And you should not update a definition once it has been added to the builder.

All these restrictions exist because the EnhancedBuilder.Build function alters the definitions. It resets the definition fields to their value at the time when the definition was added to the builder. Thus the definitions are linked to the builder and to the container it generates.

Definitions

Definition Build function

A definition only requires a Build function. It is used to create the object.

// You can either use the structure directly. &di.Def{ Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, } // Or use the NewDef function to create the definition. di.NewDef(func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil })

The Build function returns the object and an error if it can not be created.

panics in Build functions are recovered and work as if an error was returned.

Definition dependencies

The Build function can also use the container. This allows you to build objects that depend on other objects defined in the container.

MyObjectDef := di.NewDef(func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }) MyObjectWithDependencyDef := di.NewDef(func(ctn di.Container) (interface{}, error) { // Using the Get method inside the build function is safe. // Panics in this function are recovered. // But be sure to add a name to the definitions if you want understandable error messages. return &MyObjectWithDependency{ Object: ctn.Get(MyObjectDef).(*MyObject), }, nil })

You can not create a cycle in the definitions (A needs B and B needs A). If that happens, an error will be returned at the time of the creation of the object.

Definition name

You can add a name to the definition. It allows you to retrieve the definition from its name.

// Create a definition with a name. MyObjectDef := &di.Def{ Name: "my-object", Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, } // The SetName method can also be used. MyObjectDef.SetName("my-object") // Retrieve the definition from the container. ctn.Get("my-object").(*MyObject)

If you do not provide a name, a name will be automatically generated when the container is created.

:warning: Names are used in error messages. So it is recommended to set your own names to avoid troubles when debugging.

Retrieving an object from its name instead of its definition requires an additional lookup in a map[string]int. That makes it significantly slower. If performance is critical for you, you should retrieve objects from their definitions.

Another advantage of using the definitions for object retrieval is that it avoids the risk of a typo in the name.

The drawback is that you need to import the package containing the definitions which may lead to import cycles depending on your project structure.

Definition for an already built object

There is a shortcut to create a definition for an object that is already built.

MyObjectDef = di.NewDefFor(myObject) // is the same as MyObjectDef = &di.Def{ Build: func(ctn di.Container) (interface{}, error) { return myObject, nil }, }

Unshared definitions

By default, the Get method called on the same container always returns the same object. The object is created when the Get method is called for the first time. It is then stored inside the container and the same instance is returned in the next calls. That means that the Build function is only called once.

If you want to retrieve a new instance of the object each time the Get method is called, you need to set the Unshared field of the definition to true.

MyObjectDef = &di.Def{ Unshared: true, // The Build function will be called each time. Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, } // ... // o1 != o2 because of Unshared=true o1 := ctn.Get(MyObjectDef).(*MyObject) o2 := ctn.Get(MyObjectDef).(*MyObject)

Definition Close function

A definition can also have a Close function.

di.Def{ Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, Close: func(obj interface{}) error { // Assuming that MyObject has a Close method that returns an error on failure. return obj.(*MyObject).Close() }, }

This function is called when the container is deleted.

The deletion of the container must be triggered manually by calling the Delete method.

// Create the Container. app, err := builder.Build() // Retrieve an object. obj := app.Get("my-object").(*MyObject) // Delete the Container, the Close function will be called on obj. err = app.Delete()

Definition types

It is possible to set the type of the object generated by the Build function.

It is only declarative and no checks are done to ensure that this information is valid.

It can be used to retrieve an object by its type instead of its name.

You can set multiple types, for example, a structure and an interface implemented by this structure.

MyObjectDef = di.NewDefFor(myObject) // Declare that myObject is an instance of *MyObject and implements MyInterface. MyObjectDef.SetIs((*MyObject)(nil), (MyInterface)(nil)) // ... // Retrieve the object from the types. ctn.Get(reflect.TypeOf((*MyObject)(nil))).(*MyObject) ctn.Get(reflect.TypeOf((MyInterface)(nil))).(MyInterface)

:warning: If multiple definitions have the same type, the one that was added last in the builder is used to retrieve the object.

It is possible to use the NewBuildFuncForType function to generate a Build function for a given structure (or pointer to a structure). When the object is created using reflection, it will try to set the fields based on their types and the other definitions. There is also a shortcut NewDefForType to create a definition based on NewBuildFuncForType.

// Definition for an already built object, declared having the type *MyObject. MyObjectDef = di.NewDefFor(myObject).SetIs((*MyObject)(nil)) // The definition can create a *MyObjectWithDependency // and the MyObjectWithDependency.Object field will be filled with an object // from the container if there is one with the same type. // NewDefForType does not set the type of the definition. You need to call SetIs yourself if you want to. MyObjectWithDependencyDef := di.NewDefForType((*MyObjectWithDependency)(nil)) // ... // o1 == o2 o1 := ctn.Get(MyObjectWithDependencyDef).(*MyObjectWithDependency).Object o2 := ctn.Get(MyObjectDef).(*MyObject)

:warning: It is not recommended to use this because it is hard to know which fields are set and how. In addition to that, the use of reflection in the generated Build function makes it very slow. The behavior of the NewBuildFuncForType may also change in the future if ways to improve the feature are found.

Definition tags

You can add tags to a definition. Tags are not used internally by this library. They are only there to help you organize your definitions.

MyObjectDef = di.NewDefFor(myObject) tag := di.Tag{ Name: "my-tag", Args: map[string]string{ "tag-argument": "argument-value", }, Data: "Data is an interface{} if Args are not enough", } MyObjectDef.SetTags(tag) MyObjectDef.Tags[0] == tag // true

Object retrieval

When a container is asked to retrieve an object, it starts by checking if the object has already been created. If it has, the container returns the already-built instance of the object. Otherwise, it uses the Build function of the associated definition to create the object. It returns the object, but also keeps a reference to be able to return the same instance if the object is requested again (unless the definition is UnShared).

A container can only build objects defined in the same scope (scopes documentation). If the container is asked to retrieve an object that belongs to a different scope. It forwards the request to its parent.

There are three methods to retrieve an object: Get, SafeGet and Fill.

Get

Get returns an interface that can be cast afterward. If the object can not be created, the Get function panics.

// Retrieve the object from the definition (recommended) o1 := ctn.Get(MyObjectDef).(*MyObject) // Or from its name (which is slower) o2 := ctn.Get("my-object").(*MyObject) // Or from its type (even slower) o3 := ctn.Get(reflect.typeOf((*MyObject)(nil))).(*MyObject) // o1 == o2 == o3

SafeGet

Get is an easy way to retrieve an object. The problem is that it can panic. If it is a problem for you, you can use SafeGet. Instead of panicking, it returns an error.

objectInterface, err := ctn.SafeGet(MyObjectDef) // You still need to cast the interface. object, ok := objectInterface.(*MyObject) // SafeGet can also be called with a definition name or type. objectInterface, err = ctn.SafeGet("my-object") objectInterface, err = ctn.SafeGet(reflect.typeOf((*MyObject)(nil)))

Fill

The third method to retrieve an object is Fill. It returns an error if something goes wrong like SafeGet, but it may be more practical in some situations. It uses reflection to fill the given object. Using reflection makes it slower than SafeGet.

var object *MyObject err := ctn.Fill(MyObjectDef, &object) // Fill can also be called with a definition name or type. err = ctn.Fill("my-object", &object) err = ctn.Fill(reflect.typeOf((*MyObject)(nil)), &object)

Scopes

The principle

Definitions can also have a scope. They can be useful in request-based applications, such as a web application.

MyObjectDef := &di.Def{ Scope: di.Request, Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, }

The available scopes are defined when the Builder is created:

builder, err := di.NewEnhancedBuilder(di.App, di.Request)

Scopes are defined from the most generic to the most specific (eg: AppRequestSubRequest). If no scope is given to NewEnhancedBuilder, the builder is created with the three default scopes: di.App, di.Request and di.SubRequest. These scopes should be enough almost all the time.

The containers belong to one of these scopes. A container may have a parent in a more generic scope and children in a more specific scope. The builder generates a container in the most generic scope. Then the container can generate children in the next scope thanks to the SubContainer method.

A container is only able to build objects defined in its own scope, but it can retrieve objects in a more generic scope thanks to its parent. For example, a Request container can retrieve an App object, but an App container can not retrieve a Request object.

If a definition does not have a scope, the most generic scope will be used.

Scopes in practice

// Create a Builder with the default scopes (App, Request, SubRequest). builder, err := di.NewEnhancedBuilder() // Define an object in the App scope. AppDef := di.Def{ Scope: di.App, // this line is optional, di.App is the default scope Build: func(ctn di.Container) (interface{}, error) { return &MyObject{}, nil }, } err =

编辑推荐精选

蛙蛙写作

蛙蛙写作

AI小说写作助手,一站式润色、改写、扩写

蛙蛙写作—国内先进的AI写作平台,涵盖小说、学术、社交媒体等多场景。提供续写、改写、润色等功能,助力创作者高效优化写作流程。界面简洁,功能全面,适合各类写作者提升内容品质和工作效率。

AI辅助写作AI工具蛙蛙写作AI写作工具学术助手办公助手营销助手AI助手
Trae

Trae

字节跳动发布的AI编程神器IDE

Trae是一种自适应的集成开发环境(IDE),通过自动化和多元协作改变开发流程。利用Trae,团队能够更快速、精确地编写和部署代码,从而提高编程效率和项目交付速度。Trae具备上下文感知和代码自动完成功能,是提升开发效率的理想工具。

AI工具TraeAI IDE协作生产力转型热门
问小白

问小白

全能AI智能助手,随时解答生活与工作的多样问题

问小白,由元石科技研发的AI智能助手,快速准确地解答各种生活和工作问题,包括但不限于搜索、规划和社交互动,帮助用户在日常生活中提高效率,轻松管理个人事务。

热门AI助手AI对话AI工具聊天机器人
Transly

Transly

实时语音翻译/同声传译工具

Transly是一个多场景的AI大语言模型驱动的同声传译、专业翻译助手,它拥有超精准的音频识别翻译能力,几乎零延迟的使用体验和支持多国语言可以让你带它走遍全球,无论你是留学生、商务人士、韩剧美剧爱好者,还是出国游玩、多国会议、跨国追星等等,都可以满足你所有需要同传的场景需求,线上线下通用,扫除语言障碍,让全世界的语言交流不再有国界。

讯飞智文

讯飞智文

一键生成PPT和Word,让学习生活更轻松

讯飞智文是一个利用 AI 技术的项目,能够帮助用户生成 PPT 以及各类文档。无论是商业领域的市场分析报告、年度目标制定,还是学生群体的职业生涯规划、实习避坑指南,亦或是活动策划、旅游攻略等内容,它都能提供支持,帮助用户精准表达,轻松呈现各种信息。

AI办公办公工具AI工具讯飞智文AI在线生成PPTAI撰写助手多语种文档生成AI自动配图热门
讯飞星火

讯飞星火

深度推理能力全新升级,全面对标OpenAI o1

科大讯飞的星火大模型,支持语言理解、知识问答和文本创作等多功能,适用于多种文件和业务场景,提升办公和日常生活的效率。讯飞星火是一个提供丰富智能服务的平台,涵盖科技资讯、图像创作、写作辅助、编程解答、科研文献解读等功能,能为不同需求的用户提供便捷高效的帮助,助力用户轻松获取信息、解决问题,满足多样化使用场景。

热门AI开发模型训练AI工具讯飞星火大模型智能问答内容创作多语种支持智慧生活
Spark-TTS

Spark-TTS

一种基于大语言模型的高效单流解耦语音令牌文本到语音合成模型

Spark-TTS 是一个基于 PyTorch 的开源文本到语音合成项目,由多个知名机构联合参与。该项目提供了高效的 LLM(大语言模型)驱动的语音合成方案,支持语音克隆和语音创建功能,可通过命令行界面(CLI)和 Web UI 两种方式使用。用户可以根据需求调整语音的性别、音高、速度等参数,生成高质量的语音。该项目适用于多种场景,如有声读物制作、智能语音助手开发等。

咔片PPT

咔片PPT

AI助力,做PPT更简单!

咔片是一款轻量化在线演示设计工具,借助 AI 技术,实现从内容生成到智能设计的一站式 PPT 制作服务。支持多种文档格式导入生成 PPT,提供海量模板、智能美化、素材替换等功能,适用于销售、教师、学生等各类人群,能高效制作出高品质 PPT,满足不同场景演示需求。

讯飞绘文

讯飞绘文

选题、配图、成文,一站式创作,让内容运营更高效

讯飞绘文,一个AI集成平台,支持写作、选题、配图、排版和发布。高效生成适用于各类媒体的定制内容,加速品牌传播,提升内容营销效果。

热门AI辅助写作AI工具讯飞绘文内容运营AI创作个性化文章多平台分发AI助手
材料星

材料星

专业的AI公文写作平台,公文写作神器

AI 材料星,专业的 AI 公文写作辅助平台,为体制内工作人员提供高效的公文写作解决方案。拥有海量公文文库、9 大核心 AI 功能,支持 30 + 文稿类型生成,助力快速完成领导讲话、工作总结、述职报告等材料,提升办公效率,是体制打工人的得力写作神器。

下拉加载更多