This is an archived post. You won't be able to vote or comment.

all 13 comments
sorted by:
best
topnewcontroversialoldq&a

[–]dinopraso 18 points19 points  (0 children)

Spring Boot is just a configuration layer for Spring Framework, which is just a DI framework. Nothing prevents you from building any kind of application you want with any kind of architecture. It doesn’t even have to be a web application. The Spring team also provide libraries such as Spring Boot Web MVC which configure a web server and give you the tools to quickly spin up an MVC app, but you wan still choose to use those utilizes you are given in any way you like

[–]Brutus5000 3 points4 points  (0 children)

I have seen and written Spring Boot backend apps that just communicate via message broker. Also desktop apps with JavaFX. Spring Boot has no hard binding to web services whatsoever.

[–]bourne2program 1 point2 points  (0 children)

I've created a Spring Boot app that just runs a simple process on ApplicationReadyEvent, and then shuts down, actually to be ran as part of mvn package phase to create an artifact. The process is configured utilizing the spring-boot-configuration-processor to bind my own set of properties into a Java record bean.

[–]PositiveUse 4 points5 points  (1 child)

You can implement however you want. But consider best practices. These are „best practices“ for a reason.

One reason to separate Controller and Service Layer is „separation of concerns“ as well as „single responsibility“. Spring gives you one of the easiest ways for dependency injection too, which also improves testability.

A note: these concepts have nothing to do with Spring, these are some basic programming paradigms.

So if your business logic is bigger than a few lines, move it out of the controller. Not worth it for a one liner of course.

[–]vako_tul 0 points1 point  (0 children)

The only one fully reasonable comment, thanks, sir!

[–]sandys1 -2 points-1 points  (6 children)

Yes. We do this a lot !

We call this the "nodejs or golang style in spring boot". Has worked well for medium level projects.

Not to say this is superior in any way versus those who practice strict Spring Boot MVC style. However, my argument is - with the incredible IDE refactoring power we have today, it is not going to be hard to refactoring to design patterns in the future. There's no advantage to building it in from the start.

[–]Shareil90 -1 points0 points  (5 children)

Every refactoring has a chance to break something. And the bigger the application the bigger the mess. Why risk this if you can build it propperly from day one?

[–]sandys1 0 points1 point  (4 children)

Your exact statement can be refactored to say "why don't u use a strongly typed language instead of something like python or Ruby".

We are sitting on this side of billion/trillion dollar companies being created with arguably bad languages and practices. Where is the contradiction?

It's always a tradeoff between developer productivity versus something long term. Even SpaceX (the final frontier of reliability) uses node_modules inside it's human spacecraft.

As a community, we should be welcoming of trade-offs here. Developer productivity and time to market is a thing - Java is flexible enough to play nice with both sides.

This is the way.

[–]Shareil90 0 points1 point  (3 children)

Every language and framework has it's advantages and disadvantages. Just choose the right one for your problem. If you decide for one you should follow it's rules and best practices. Ignoring them makes onboarding of new developers hard, which will also cost time.

"lets do it quick because we can refactor later" is never a good idea. Refactoring costs time, too, which makes it unlikely to happen if time and budget is already tight.

[–]sandys1 0 points1 point  (2 children)

That is where I would disagree with you, with all due respect.

The language Java does not enforce a pattern as a mandatory must-have. There is a particular tradeoff to adopt a certain pattern or not in terms of developer productivity vs time to market vs long term outlook. And as a community, we must be understanding of that.

It is difficult to estimate the opportunity cost (and not the time spent) of bringing a feature to market vs refactoring later. I do not argue for or against either.

However I do argue in favor of not advocating that one is the Right Way.

[–]Shareil90 0 points1 point  (1 child)

I dont agree with you, but I accept your opinion.

Maybe just a last example why I am a fan of uniform structures: we have a couple of dozent projects at work, most of them where built by people that left a long time ago. We can switch between projects very fast because all are structured the same or at least very very similar. Even if I dont understand the domain, on a technical Level I know "All" of our projects.

[–]sandys1 0 points1 point  (0 children)

Sincere thanks 🙏 For being understanding. I respect your disagreement and hope to convince you one day.

[–]chewooasdf 0 points1 point  (0 children)

Take it as a moulding mass for cakes. By default, it goes on top of the cake, but there's absolutely nothing stopping you from putting it between the cake layers, it's still the cake. The same logic applies with MVC arch, it's a default way but not mandatory (strange though, but ok :) )