Simple dependency injection, based on KotlinSerialization
Go to file
2020-08-12 12:56:12 +06:00
gradle/wrapper version 0.2.0 2020-03-22 18:26:41 +06:00
src v0.3.0 2020-04-15 10:12:08 +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
.travis.yml add allTests task into travis build task 2020-03-22 18:27:17 +06:00
build.gradle start 0.3.1 2020-08-12 12:55:04 +06:00
CHANGELOG.md update kotlin version 2020-08-12 12:56:12 +06:00
gradle.properties update kotlin version 2020-08-12 12:56:12 +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
maven.publish.gradle update publish scripts 2020-01-19 14:07:11 +06:00
mpp_publish_config.json update publish scripts 2020-01-19 14:07:11 +06:00
publish.gradle update publish scripts 2020-01-19 14:07:11 +06:00
README.md fill travis and badges 2020-02-19 20:18:35 +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.