A modern programming language that makes developers happier.

kotlinlang

This might help: <https://spring.io/guides/tutorials/spring-boot-kotlin/> see the UserController class

I've been through this. I understand how to accomplish the functionality I'm pursuing, just wondering if there is a more kotlin-styled approach to it

there’s a solution unrelated to kotlin
but i’d advise against it
as it relies on AOP
<https://blog.frankel.ch/oop-compatible-enterprise-context/#the-final-touch>

crazy that this is actually the first time I've heard of the term "Aspect-Oriented Programming"

I remember a Spring project from way back, I think it was called Roo, which tried to do everything with aspects, it was kind of question-answer interactive spring application builder.
edit----
Looks like it's still somewhat alive, too! 2.0 was released last year, no "real" commits to master since then though...

<@UB598EG6L> happy to have been of service :slightly_smiling_face:

yes, i remember about spring roo
it was a generator
it was heavily inspired by ruby on rails for the concept
but in ruby, it’s easy to add behavior at runtime
not in java
so the implementation was based on aspects
though you could remove them afterwards if you didn’t like it

aaahhh, spring roo, completely forgot about it. I tried it, but never went past prototyping, too different than anything else was in our code base at the time (and for what I remember it would be a weird fit now too)

You are correct that Beans can't be static (talking in Java terms). They are always a property on something as Spring injects them as part of class creation/construction/initialization.

You could potentially do something with a custom Component and extension functions. Might be a bit ugly as you're mixing class and object properties here to accomplish it, but I think it's feasible.. Haven't tried it as I'm so used to `userRepository.save(user)` that I didn't even consider adding `save` to the User class.

I’d suggest it being difficult to inject an `@Repository` into an `@Entity` is a _feature_.

If you are looking to do an ActiveRecord type pattern, then you probably do not want to use the Repository abstraction in the first place (and you’ll be, imo, conflating separate tiers of your architecture).

In the Repository pattern, there is a distinction between the Entities being persisted (data class) and the classes that actually interact with the database (Repositories). It enforces a nice separation of concerns.  IMO if you start doing things within the Entity itself, then you’ve also just made proper transaction boundaries much more difficult to define and/or understand onc ethey’re defined.

i disagree *a lot*
what you refer to as an `@Entity`
some refer to as a data structure
which is not OOP
so this pattern of yours is an anti-pattern to others

for sure, ActiveRecord 100% exists. I’m referring to specifically the Spring Programming Model, which has `@Entity` and `@Repository` and has an architectural specific distinction between the two

i wasn’t saying your pattern is bad, just that if you’re trying to achieve that pattern, using Spring Repositories and Entities may not be the most seemless fit.

for sure, it’s not the best fit :joy:
but i toyed with the idea for some time
see the above post
never tried it for real though
either you should embrace a framework, or discard it
not fight it