Simple dependency injection, based on KotlinSerialization
Go to file
2021-06-05 17:37:19 +06:00
.github/workflows add build workflow 2021-02-17 00:45:01 +06:00
gradle/wrapper update gradle wrapper 2021-02-17 00:44:04 +06:00
src fixes in ModuleSerializer 2021-06-05 16:16:59 +06:00
_config.yml Add '_config.yml' 2020-02-11 11:21:51 +00:00
.gitignore init 2019-11-19 18:16:59 +06:00
build.gradle Update build.gradle 2021-06-05 17:37:19 +06:00
changelog_parser.sh add github release plugin 2020-11-11 23:39:14 +06:00
CHANGELOG.md fill changelog 2021-06-05 16:18:52 +06:00
github_release.gradle add github release plugin 2020-11-11 23:39:14 +06:00
gradle.properties update dependencies 2021-06-05 13:33:52 +06:00
gradlew init 2019-11-19 18:16:59 +06:00
gradlew.bat init 2019-11-19 18:16:59 +06:00
LICENSE Initial commit 2019-11-19 09:24:10 +00:00
mpp_publish_config.kpsb update publish scripts 2021-02-19 19:33:57 +06:00
publish.gradle update publish scripts 2021-02-19 19:33:57 +06:00
README.md updates 2021-01-20 12:02:49 +06:00
settings.gradle updates 2019-11-22 10:11:31 +06:00

SDI

Download Maven Central Build Status

It is simple (in comparison with other systems) DI, which aim to be compatible and predictable. This library was created with aim on difficult systems with opportunity to reconfigure most parts of behaviours without recompilation of code.

Platforms support

  • JVM
  • JS
  • Native

Required environment

To use this library you will need two things:

  • Json serializer
  • Json config

Unfortunately, currently not supported other formats (due to issue in Kotlinx.serialization)

How to implement

Currently you can connect repository JCenter:

repositories {
    // ...
    jcenter()
    // ...
}

and implement it like here:

dependencies {
    implementation "com.insanusmokrassar:sdi:$sdi_version"
}

Last version shown here: Download

Format of config

Full examples of usage you can find in tests. In two words, there are a few rules for constructing of config:

  • Config root is an Json Object
  • Config root names will be used as dependency names
  • In the config dependency names can be used everywhere
  • In places, where dependency will be injected, must be used @ContextualSerializer annotation or @Serializer(ContextSerializer::class)

Examples

Lets imagine, that we have several interfaces and classes:

package com.example

// ... //

interface ControllerAPI {
    fun showUp()
}
interface ServiceAPI {
    val names: List<String>
}

@Serializable
class Controller(@ContextualSerialization val service: ServiceAPI) : ControllerAPI {
    override fun showUp() {
        println("Inited with name \"${service.names}\"")
    }
}
@Serializable
class BusinessService(override val names: List<String>) : ServiceAPI

Here there is common way to create all of this directly:

val service = BusinessService(listOf("One", "Two"))
val controller = Controller(service)

And with config for this library:

{
  "service": [
    "com.example.BusinessService",
    {
      "names": ["One", "Two"]
    }
  ],
  "controller": [
    "com.example.Controller",
    {
      "service": "service"
    }
  ]
}

Kotlin code will be:

val module = loadModule(input)
val businessService = (module["service"] as BusinessService)

Here input is a json of configuration.

List example you can find in this test. Besides, usually you can create objects inside of places where expected something like dependency injection directly. In this case config will look like:

{
  "controller": [
    "com.example.Controller",
    {
      "service": [
        "com.example.BusinessService",
        {
          "names": ["One", "Two"]
        }
      ]
    }
  ]
}

More expanded example you can find in suitable test.