This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I've recently started reading about Spring and wanted to know if it can be used without the AOP features (I could not grasp the concepts of AOP on my first attempt)? Are there is disadvantages of going this route?
Exactly. But you can still use AOP, without you having to know AOP. What I mean by that is some of the services are added via AOP underneath the covers. Things like Transactions are added via using Spring AOP, and you don't even need to know AOP to configure transactions in Spring.
But to help you understand AOP, I wanted to type the concepts and definitions for you and see if my explanations help clarify them. I am going to use them in terms of Spring AOP. AOP has many implementations and they can go a bit further.
1) JoinPoint - The is the one place where Spring AOP is a subset of a full blown AOP. In Spring AOP, a Joinpoint is any method in your application's code where you want "other" code to be run/injected.
2) Advice is the "other" code that you want to be run/injected into your application code. It is code that isn't written in your clean application code, but separated out into its own method in its own class. Things like transaction handling, exception handling, logging, security code.
3) Aspect is the class that holds the advice method.
4) Pointcut. Because the advice code is separated from your application code, you need to tell AOP how to know which methods in your application code you want to run/inject you advice code. So in order to "hook" them up, you use a special expression language that can define which application methods (joinpoints) you want to (advice with code). Using this expression language you create a Pointcut that defines that hook.
You use AOP to write advice code like say security code, so that in your application code you don't have security check code in almost every method.
I have learned Core Spring (IOC), Spring JDBC, Spring MVC, Spring AOP, Transactions, Integration with hibernate,struts,tiles. I also read little bit about Spring Security but don't know much on spring security.
The question I have is, is it enough for me to write on my resume that I know Spring.
If you test yourself with a hello world application spring style and succeed you have a pretty good reason to put spring into your CV.
Just do a simple test. Think of a very simple application that has one or 2 screens that reads/write from/to a database and want to do something with it. Build it and after succeeding think of a real life scenario and if you feel confident that you can handle it definitely put the skills in.
The test should give you an idea on how deep your understanding of the concepts really is and how easily you find your way through the implementation (eg. Spring) to make it work.
If you say even for the hello world app that using Spring is overkill, change the task. For ex: take the hello text from a dictionary table giving the locale. Even further, have a user object that when creates the session has to set a language and based on that get the texts from the dictionary etc...evolve it towards a full blown user profile management app and you will see how spring eliminates boilerplate code and when you managed all that and said...that was easy...you're DEFINITELY ready.