Hello, I recently started using Ktor and noticed i...

# ktor

[ShiinaKin]

Hello, I recently started using Ktor and noticed in the ktor-samples repository, specifically in the mvc-web project, that controllers are used in a certain way. Is this the officially recommended best practice, or is it possible to define controllers as singleton classes instead of creating a new instance for each call?

[Jan Danecki]

I'm not expert in ktor but this doesn't looks fine. All those dependencies created in place

[ShiinaKin]

Yes, that's exactly what I found strange as well, but since it's from the official repository, that's why I had this question.

[Hristijan]

They're just samples as you can see, the controller shouldn't be behaving like this since this is in memory demo

Service Layer should contain business logic and interacts with repositories

[ShiinaKin]

fun Route.settingRoute() {
    route("test") {
        get("xx") {
            SettingController.handleXXX()
        }
    }
}

object SettingController {
    suspend fun handleXXX() {
        
    }
}

// So, is it correct to set the Controller as an object class and register routes uniformly in the Router like that?

[Hristijan]

Yes that's one approach

[Jan Danecki]

I wouldn't recommend that, because it quickly gets ugly with dependencies

[Jan Danecki]

unless you are using static dependencies which I also don't recommend 😛

[Jan Danecki]

Actually I kind of like FP approach I learn while I was working with scala

fun Route.eventsRouting(foo: Foo, bar:Bar) {
        eventsBasicRouting(foo)
        eventsSomething(foo, bar)
    }

    private fun Route.eventsBasicRouting(foo: Foo) {
        route("/events") {
            getEvents(foo)
        }
    private fun Route.getEvents(foo: Foo) {
        get(getAllEventsDocs) {
               //some logic
            }
        }

[Jan Danecki]

and later in some main config place

fun Application.wireApplication(config: ApplicationConfig) {
    val foo = Foo()
    val bar = Bar()

 

    routing {
        healthCheck()
        authenticate(Auth.FRONT_AUTH) {
            eventsRouting(foo, bar)
        }
        //And so one
    }
}

[Jan Danecki]

and lastly

fun Application.module() {
    wireApplication([e-mail])
}

[ShiinaKin]

Thank you for your replies.
@Jan Danecki your suggestion was really helpful, and I'll try to use it in my project. However, since the project is quite small, I'm not sure if it's necessary to go that far. 😜

[Jan Danecki]

honestly it works really well for small project

[Jan Danecki]

just don't split it do much

[Jan Danecki]

you can keep all in one place and split when needed

[Jan Danecki]

main idea is to use DI, so your code should be easier to develop

[Hristijan]

you can keep all in one place and split when needed

That's what I'm doing at the moment

Ex.

fun Application.user() {
routing {
signUpWithEmail()
refreshToken()
signInWithEmail()
signInWithSocial()
deleteUser()
changePassword()
userDetails()
editUserDetails()
forgotPassword()
resetPassword()
}
}

And other functions are small units

[Jan Danecki]

exactly

[Hristijan]

Use whatever approach works for you, MVC, FP etc...

If you want to isolate more tests, use MVC

Since I'm using integration tests only, this is easily testable too

[ShiinaKin]

routing {
    route("api") {
        commonRoute()
        imageRoute()
        albumRoute()
        strategyRoute()
        settingRoute()
        userRoute()
        groupRoute()
        roleRoute()
    }
    staticResources("", "static")
}

This is what I'm currently doing, and it seems I need to break it down even further in the next layer.

[ShiinaKin]

Okay, I'll give it a try 😄

[Jan Danecki]

mostly, my concern is where do you create dependencies etc

[Jan Danecki]

because DI approach helps with tests etc

[Hristijan]

I'm using manual DI and usually injecting the constructors of the repository with default arguments since most of the things required are singletons but the repositories are short lived objects, so that I can easily call MyClass()

[ShiinaKin]

well, i am now thinking of creating dependency instances in the overall collection and passing them down sequentially.

[ShiinaKin]

//center
router {
     val service = xxServiceImpl()

     xxRoute(service)
}


class xxController(val xxService: xxService) {
    fun handleX() {
        xxService.foo()
    }
}

fun Route.xxRoute(xxService: xxService) {
    val controller = xxController(xxService)
    get {
        controller.handleX()
    }
    // postxx()...
}

What I'm currently thinking is to do it like this, and it seems that there's no need to manage it with a k-v map like spring.
Forgive my previous misunderstanding, my poor English 😢

[ShiinaKin]

Finally, thank you again for your replies, such a friendly community 😄

[Jan Danecki]

that looks similar to what I'm doing 😉