The only thing I ever use Spring for is to help manage my DAO's and Services. To be more specific I create a datasource, inject that into a jdbcTemplate, inject that into a DAO, and at times, inject one or more DAO's into one or more Service classes.
While this works well, it does create the Spring dependencies in my project. And while that normally isn't a big deal, in general, I wonder if it's overkill.
my opinion is this, when you use a 3rd party framework in your application you will create dependencies, like if you choose to use struts for a MVC/presentation you're going to use actions/forms ect creating a dependency on struts. I would imagine the same thing goes for back end, like using spring for service/dao patterns. Spring is nice because you're just injecting everything into your daos, services ect. If you really needed to it wouldn't be much work to rip out spring and add a util class that gets your datasource and connection and things like that. I use spring/hibernate for all my projects and I have no issues writing for those because if I were to strip those out of my projects it would most likely be a rewrite, with the exception of my pojos... That's my $0.02
The only thing I ever use Spring for is to help manage my DAO's and Services.
I'm not really debating whether this should be a good enough reason for using Spring or not, but I would rather feel that if this is the only reason for you to use Spring then in my opinion you're missing the most important reasons for doing so. I could only suggest you to look at the larger picture: Spring is a great framework that helps you following a lightweight development approach. It really helps you to benefit of implicit middleware services without the need of using a heavyweight container. For years the fact that EJBs were able to provide declarative transaction management was the unbeatable reason of using EJBs and the heavy containers. Spring provides the same capabilities through AOP, which has even support for nested transactions. This is true for all other services the heavyweight containers provide. Another important reason to consider is the testing capabilities. In a nutshell the dependency injection paradigm and the fact that you're building only pojos helps you design and build your code for testability (you're not dependent upon any container for running your unit tests). This is another thing that developers seem to overlook; there is always a difference between designing a class and designing a fully testable class. Using jMock on the other hand you should be able to write code that is 100% covered. Run a code quality report tool regularly on your code, use eclipse with PMD and checkstyle pluggings and you should be proud of your code quality. It fells like you're doing the right things right. There is probably more to say about this but I have to run to a meeting :-) I'll talk to you soon.
I think, therefore I exist -- Rene Descartes
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad: