91–100 of 119 posts
In terms of the popularity of the two frameworks, all I can say is that I have been interviewing 2-3 Java engineers per week for the past few months, and almost all of them put Spring on their resume and not Java EE.
After using Spring Boot for 2 years now, I'll never go back to EE.
Earlier quoted context omitted.
I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here. I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". Dependency injection is important because it provides a healthy way to compose an application from man…
> I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". DI creates debugging nightmares by moving what used to be compile time checks to runtime. Fowler was wrong.
My viewpoint is, roughly:
1) DI, as described in the GoF book is a great pattern. You compose objects by passing other objects to its constructor as needed. These are the stored in final fields for the lifetime of the parent object. The pattern gives a lot of flexibility and handles a lot of use cases which it may otherwise be tempting to handle using the inferior concept of inheritance. It's simple, it's typesafe, it's easy to debug.
2) DI, as implemented by virtually any DI framework, is the Devil. Most DI frameworks is little more than a big dictionary mapping interface types (or magic strings) to implementation classes, along with some black-box magic to make it work (and bloat your stacktraces). It saves you the effort of calling constructors explicitly but any gains are lost as soon as you need to debug stuff. It shares a lot of traits with that other big dictionary where you can dump stuff for convenience: the global scope. It also has the same backdraws.
But anyway, this is a minority position so there is a large chance that I'm dead wrong and a small chance that history will prove me right.
Earlier quoted context omitted.
Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you c…
It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you sudd…
Earlier quoted context omitted.
Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you c…
It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you sudd…
I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old.
The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.
Earlier quoted context omitted.
Nope. There is no difference between injection types from the coupling perspective, simply because neither blocks anything bad from happening in your architecture. There are reasons to prefer constructor injection in many cases, but it has nothing to do with modularity or coupling.
With Constructor based injection its easier to see layering and coupling issues as once your constructor gets more that 3-4 parameters then it starts becoming blindingly obvious that the class has too many dependencies and needs to be refactored. This helps keep the bad out of the architecture. The main reason to favor constructor based injection is that it stops objects becoming 'live' in an inconsistent state. I've…
Earlier quoted context omitted.
That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.
It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.
I like Java, but I've never tried diving into the Spring or Java EE world. The little I've looked at it seem daunting and complex and I'm not sure what it really gives you at the end of the day. What functionality does it provide, what are the killer features? And is all this complexity justified?
I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal. Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...). I'm personally only familiar with Spring. An…
Almost every time the answer for me has been "it seems like they have, but they don't handle a critical edge case of some kind and cannot be extended to, and thus their solution is totally useless."
> for example here’s a copy from Lightbend (the company behind Scala, Play & Lagom) I use Play 2 for most of my projects and frankly knowing what I know about Spring and J2EE (even though having never worked with them for the same reason) I couldn't really think of any reason to choose either of these outdated behemoths. With something like Play 2 and Slick/JOOQ you could run circles around these two.
Opinionated frameworks are fine to get started quickly, but for larger scale companies, you are gunna want flexibility beyond that.
If I want to build a web app from scratch which should have some basic features (user identification, some standard level of security, REST interface, database integration) and I have some okay knowledge of Java (mainly CLI applications and some Android programming), which framework would you recommend for me to get started? I'm afraid to get lost in the details too quickly, so a framework that provides a working exa…
I'd recommend Grails. https://grails.org/ You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.
Earlier quoted context omitted.
It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! Well, you care when you have an unexpected complex circular dependency or you need to refactor and you sudd…
> When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring! I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old. The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example…
The same should apply to repositories unless it is absolutely necessary. It should ideally just know enough to manage itself
A service may reference other services if it needs to coordinate actions. We need to be careful not to make huge services that contains too much logic though
I have found that this pattern makes it not only easier to structure the application, but also much easier to make mocked tests.