SDI/README.md

143 lines
3.7 KiB
Markdown
Raw Normal View History

2019-11-19 09:24:10 +00:00
# SDI
2020-02-19 14:18:35 +00:00
[ ![Download](https://api.bintray.com/packages/insanusmokrassar/InsanusMokrassar/sdi/images/download.svg) ](https://bintray.com/insanusmokrassar/InsanusMokrassar/sdi/_latestVersion)
[![Maven Central](https://maven-badges.herokuapp.com/maven-central/com.github.insanusmokrassar/sdi/badge.svg)](https://maven-badges.herokuapp.com/maven-central/com.github.insanusmokrassar/sdi)
[![Build Status](https://travis-ci.com/InsanusMokrassar/SDI.svg?branch=master)](https://travis-ci.com/InsanusMokrassar/SDI)
2020-02-15 08:42:50 +00:00
It is simple (in comparison with other systems) DI, which aim to be compatible and predictable. This library was created
2020-02-15 08:43:44 +00:00
with aim on difficult systems with opportunity to reconfigure most parts of behaviours without recompilation of code.
2019-11-27 16:25:19 +00:00
2020-01-19 08:51:22 +00:00
## Platforms support
2019-11-27 16:25:19 +00:00
* [x] 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](https://github.com/Kotlin/kotlinx.serialization/issues/615))
2020-02-10 11:50:49 +00:00
## How to implement
Currently you can connect repository JCenter:
```groovy
repositories {
// ...
jcenter()
// ...
}
```
and implement it like here:
```groovy
dependencies {
implementation "com.insanusmokrassar:sdi:$sdi_version"
}
```
Last version shown here: [ ![Download](https://api.bintray.com/packages/insanusmokrassar/InsanusMokrassar/sdi/images/download.svg) ](https://bintray.com/insanusmokrassar/InsanusMokrassar/sdi/_latestVersion)
2020-01-19 08:51:22 +00:00
## Format of config
2019-11-27 16:25:19 +00:00
Full examples of usage you can find in [tests](src/commonTest/kotlin/com/insanusmokrassar/sdi). 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)`
2020-01-19 08:51:22 +00:00
### Examples
Lets imagine, that we have several interfaces and classes:
```kotlin
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:
```kotlin
val service = BusinessService(listOf("One", "Two"))
val controller = Controller(service)
```
And with config for this library:
```json
{
"service": [
"com.example.BusinessService",
{
"names": ["One", "Two"]
}
],
"controller": [
"com.example.Controller",
{
"service": "service"
}
]
}
```
2020-02-10 11:55:00 +00:00
Kotlin code will be:
```kotlin
2020-02-15 08:35:03 +00:00
val module = loadModule(input)
2020-02-10 11:55:00 +00:00
val businessService = (module["service"] as BusinessService)
```
Here `input` is a json of configuration.
2020-01-19 08:51:22 +00:00
List example you can find in
[this test](https://git.insanusmokrassar.com/InsanusMokrassar/SDI/src/master/src/commonTest/kotlin/com/insanusmokrassar/sdi/ListTest.kt).
Besides, usually you can create objects inside of places where expected something like dependency injection directly. In
this case config will look like:
```json
{
"controller": [
"com.example.Controller",
{
"service": [
"com.example.BusinessService",
{
"names": ["One", "Two"]
}
]
}
]
}
```
More expanded example you can find in
[suitable test](https://git.insanusmokrassar.com/InsanusMokrassar/SDI/src/master/src/commonTest/kotlin/com/insanusmokrassar/sdi/SimpleCustomObjectTest.kt#L63).