My book, my movies, my videos, my podcasts, my events ... the big collection of paul wheaton stuff!
It may not look like it in "hello world" examples, but I'm seeing 20 lines of Java code replaced by 4 lines of XML that are a lot less likely to be buggy. The code also becomes a lot easier to unit test because all collaborators are parameterized. Finally, I find that the dependency injection approach encourages the team to employ a more decoupled OO programming style that produces better maintainable code generally.Originally posted by Paul Wheaton:
I tried to learn about Spring, but I guess I must be thick. It looks like the goal is to replace four lines of java code with 20 lines of XML and say that it's simpler because there is now less java.
Spring is not "a replacement for EJB" as such. It's something that is a viable (and indeed preferable) alternative to EJBs for a large number of use cases. Spring does not aim to replace EJBs wholesale - they both have their place.It's touted as a lightweight replacement for EJB. But it doesn't have clustering unless you put it in an EJB container
Hibernate is a fabulous tool. But make no mistake, working with an O/R mapper is fundamentally different from working with JDBC (or a JDBC wrapper such as iBatis or Spring) and you will need to get up a sizeable learning curve once you start using it in anger.And I find dead bodies behind lots of O/R tools. I just haven't found any dead bodies behind hibernate .... yet. Any O/R tool makes me squeemish.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
My book, my movies, my videos, my podcasts, my events ... the big collection of paul wheaton stuff!
Well, you don't need Spring for that, and given that remote APIs should be radically different from local interfaces you would in practice expect at least a local business facade to adapt between local and remote APIs. So much for transparency.Originally posted by Paul Wheaton:
One approach to using it is that your client can be unaware of whether it is a POJO in the same VM or an EJB on another box. While this can be cool, it seems that you would want to have a business need for this feature.
Spring AOP is about an evolutionary rather than revolutionary use of AOP. You aren't surprised or worried when container transaction management shows up in an EJB tier stack trace, even though it's not in the EJB source - why should you be any more surprised when Spring transaction aspects shows up in the stack trace?AOP is another thing that has a very high cool factor and a very high heebie jeebie factor. I suppose AOP within a small library is okay. But for in-house use, it seems like it can easily add to maintenance and debug headaches. Some guy opens some code a year down the road and is trying to fix an old bug - the debugger (or stack trace) insists that there is a method being called in a class that just isn't in the source...
Absolutely true; physics students call it "the law of conservation of misery". The designer's trick is to move the warts to where they hurt least for the project at hand.Hibernate: one of the guys at the conference said an interesting thing. Something like relational stuff and object stuff just doesn't mix well. There will always be warts. And each O/R product is just going to move the warts to a different place.
IMHO, Spring provides something better: you get a choice between using XML configuration or @annotations to declare transactional behaviour, and if you wish you can dictate exactly which exceptions roll the transaction back and which ones don't. And that's just the out of the box stuff; if you need some totally custom behaviour, you can implement your own transactional aspects.[...] It does seem that a lot of the failover/clustering features are better served by a good router. So you could then use servlets. The transaction stuff in EJB is pretty sweet and apparently spring provides something almost as good.
You might enjoy J2EE without EJB when it comes out. I'm prejudiced though - I reviewed a number of chapters.I dunno. I guess I felt that spring was being hyped pretty hard and it would have been nice to have a point by point comparison on spring vs. EJB vs. servlets.
IMHO, Spring is as good as the hype; the most significant disadvantage I found is the learning curve the team had to go through (but we went the whole hog at once: Spring container, AOP, Spring MVC framework, Hibernate...).I just wanted to feel around here and see if these things are as good as the hype and I should pay closer attention, or if these guys are neglecting to report the downsides.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
You're absolutely correct. I was thinking of independent scaling of web and business tiers - and therefore, remoting between them.Originally posted by Chris Mathews:
I think the comments about clustering are a bit off the mark. A Spring application can certainly be clustered without the use of an EJB Container. We would just be clustering at the web application tier. [...]
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Andres Camacho:
The thing that is not clear to me yet is the relationship between the DAO objects and the MVC form objects in Spring. Are they separate? Can they be the same? Does anyone know of a good example that showcases not only the Hibernate side of Spring but also the MVC working together?
Spring Boot in Action - Spring made easy!
Spring in Action - Build powerful applications!
Build Talking Apps for Alexa - Add voice to your applications!
She'll be back. I'm just gonna wait here. With this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|