4 ms·
If we apply your logic, then every mainstream language has the coloring problem with not just two, but a multitude of colors. // OMG we can't call this witho
by koiueo 1y ago
If we apply your logic, then every mainstream language has the coloring problem with not just two, but a multitude of colors.
// OMG we can't call this without passing the service
// This function is people-colored
public Person findPersonByName(PeopleService service, String name) {
// OMG we can't find without the service
service.find(name)
}
EDIT: formatting
- vips7L 1y agoThis is off topic. But I really hate “services”. They always are just some random collection of functions and aren’t a real object at all.
- koiueo 1y agoI think I know what you are talking about. In a typical three-tier enterprise application there's no clear separation of concerns between "services" and DAO/Repo... And this is due to how most persistence libraries are designed: they eagerly execute side-effects, this breaks composability due to poor transaction control, so you end up leaking a lot of your business logic into your supposedly persistence layer. Take a look at Scala's doobie[1]. Any doobie operation returns a `ConnectionIO`, which is only a description of an operation (free monad). With a proper doobie usage the DAO layer is an algebra of possible persistence-related operations, and the service layer implements business logic by combining primitive ConnectionIOs and interpreting them with full control of transaction boundaries. [1] https://typelevel.org/doobie/index.html https://typelevel.org/doobie/index.html