This article gives an introduction to the Spring framework, including Spring aspect-oriented programming (AOP) and the Inversion of Control (IOC) container. It provides an example to inject dependencies, or services, into a working credit card account application rather than having to build them in from the ground up.
I think that the present lack of comments on this article, combined with the subject matter of this article, speaks volumes about the so-called osnews community.
Not that your input helped much in the matter either.
Things are always slower around here in the weekends. S’ppose people have the so-called “life”.
says nothing to around 95% of all osnews readers, but back to the topic. Spring has been heavens sent, it is not really an intrusive next webframework (although it can be) but more a supportive library which takes away most of the problems many J2EE interfaces have.
First, it introduces IOC which solves a number of problem mainly in team development and testing. Then it adds to that very simplified interfaces on the DB layer and generally Data access layer (which includes webservices) it adds aspects to make things even easier, and then it also does some lightweight webframework stuff.
All this functionality is loosely coupled together, so that you can use some stuff in your projects and omit the other without compromising anything.
Spring is one of the few recent frameworks which are a sheer joy to use.
Maybe you might like:
http://tools.devchannel.org/devtoolschannel/04/04/15/1457223.shtml?…
easy article, short, and talks mainly about the AOP side of Spring + an example. You might like it, and it might make you understand it more. I have to say however, that Spring isn’t the only way to add “AOP” to your program, and some other solutions are way different…
look at my DNS Output and look at the comment some ass-hole posted, we are not the same person
Something like this for PHP would be nice. If you don’t host your own site and want to pay normal prices (or if you cheap) that’s what your stuck with. You know Java, you prefer Python, you just learned Ruby on Rails? Bad luck that besides PHP you can only get python and perl CGI.
P.S.: Python CGI doesn’t cut it.
I never really grasped the concept of Aspect-Oriented Programming – how is it different from OOP?
– Simon
Python for example:
>>> class A:
… pass
…
>>> a = A()
>>> def myFn(self):
… print self
…
>>> A.myFn = myFn()
>>> a.foo()
<__main__.A instance at 0x40be40>
>>> del myFn # clean out the root namespace
>>> a.foo()
<__main__.A instance at 0x40be40>
Preview button showed that the non-breaking spaces would render correctly, not be written out *ugh*
Spring has brough fresh blood to Java-J2EE application develpement. it simply enforces you to apply good enterprise programming practises, and glues many tool nicely, reduces code size, makes it easier to test without intrusion.
it makes it easy to develop highly maintainable J2EE projects without the need of application servers or EJB (Note that J2EE does not mean EJB or App servers only). But of course, some projects still need App servers and EJB’s spring fits there too nicely. AOP – Ioc are only some aspects of Spring. EJB3 will have similarities to Spring, and that is a good thing.
As I understand it (and I have no practical experience of it) AOP is the ability to implement so called “cross cutting concerns” in a way that makes the concern totally independent of the place where it’s being used.
The common example is Logging – a concern or service that’s needed everywhere in an enterprise app. The idea is that instead of logging being implemented everywhere it’s needed, the framework unobtrusively manages logging and your regular code doesn’t know anything about it -there are no interfaces, no inheiritance, no special calls.
Spring is supposed to make this possible.
Could be wrong about all of the above, it’s based on a 2 minute conversation I had with a techie about AOP a few weeks back.
This is how I understood it when I looked at it a bit ago. If someone wants to correct me, please do.
The problem AOP tries to solve is that of dispersed code. There’re some operations which end up being used in many places and that makes mantainability a bit harder.
You maybe have to call some authorization routines before any transaction, or maybe in your model there’s some tables that always need to be notified of changes in other tables, or the much used example of logging (or more generally notifying an external system)… The thing is you can (should) encapsulate that functionality in a class, module or whatever. Right, but the calls themselves, the calls to those methods still remain all over the place. So if you change the behaviour of that functionality, you might still end up having to change a lot of dispersed lines (maybe just 1 line, but in many separate places).
AOP tries to leverage that by letting you say to the system: Ok, whenever I’m calling such and such, you have to execute this before (or after, or both). And then the system (think of it kind of like preprocessing) introduces the appropiate calls.
Then, to change some behaviour, you just change that.
It allows you to actually “cut” into objects/methods and bind them together with other objects/methods without the need to change the code of the objects. Sort of an extension to the component (or javabean) based programming.
“CreateCreditCardAccountInterface”
MyEyesHurtWhenIReadThis
Solves those problems, in bigger systems there often are concerns which are scattered all over the code which basically have nothing to do with the business logic itself.
The classical example is logging. Basically all of error handling is the better example.
In a classical program you basically have to throw an exception, or the exception gets thrown, you have to catch it somewhere and do something with it.
Now you have a system which becomes bigger, all this standardized error handling is called from 500 different places all over the app.
With an AOP system you can define the error handling interception externally and you do not have to care about that stuff in your business code.
Another classical example would be to set predefined methods automatically in a transaction scope and do the transaction handling as well at the AOP side of things.
What happens is, that you just write your business code, you do not have to take care about session handling, opening closing of transactions or the error handling of the errors, all you do is the business logic and have all the infrastructure cross cutting concerns be handled in a centralized way, without touching your business methods at all from a code point of view.
Of course all this stuff would not bee needed in a more dynamic environment like smalltalk where you can do this stuff on the fly, but in statically languages like java or C++ this stuff is heavens sent as soon as the systems become bigger.
The downside of AOP is, if you overdo or misuse this stuff, it can become very dangerous for code readability, so use it wisely and use it with care and benefit from it.
> The classical example is logging.
For a good log you need location specific context and location specific spotting. You don’t need a simple method trace or an arg dump.
> all this standardized error handling
Either you rethrow ore your method has to handle the error there in a way the would not be generic.
I also think transaction scope by method is as silly as java’s locking by method, but I’ll leave that one alone.
you do not get the point fully, I talk ways to so solve problems of code cluttering, which can be centralized viao aop or at least taken out of the algorithmic businesss context, you talk about problems of implementation details.
First of all, AOP forces you to nothing, if you do not like to put a method under transactional scope via aop, you do not have to do it.
But to my experience the DAO pattern and especially methods which basically start with a single transaction scope and end with the end of transaction and the error handlers are around 80% of all database access methods in a typical business app. Those 80% have usually session handling code, transactional code and standardized error logging code which mostly is the same and which basically makes up 30% of the methods, the specialized error handling usually is not done on this level, but much much higher in the middle tier.
AOP is one way to resolve the problem of getting this code out of the core algorithms and one with a very loose coupling, another one would be to move the business code into separate methods, another one would be to have a capsule class which uses the business code as callback within the capsule.
AOP just gives you the ability to do it in a a little bit cleaner way, and depending on the aop system in a centraliced manner, where it can be easly located and altered for the entire system.
I did not say there are other ways to do it, but it is one way to do it, which works very well.
As for the error example, I did not say, error handling and logging does not often need specialized treatment, but given the experiences of my last project I could move around 80% of all possible error messages into reusable automated mechanisms, with all the database level errors done by one interceptor (I did not use AOP back then, due to limits imposed on my by my patterns or more the way Spring introduces AOP over proxy classes)
All I still had to write myself were specialized user application logic errors and those only were a handful, and probably also movable into something more centralized.
AOP would have given me more decoupling of that error code, than I have with interceptors, but the interceptors come close enough.
But as for another example for AOP would be to introduce debugging or whatever functionality into big old legacy systems nobody really wants to touch, this is close to misuse of the concept, but currently used very often. I can recall one case where they introduced AOP logging on top of an old big system to get a cleaner picuture of the programmatic flow.
http://blog.arendsen.net/index.php/2005/03/20/a-feel-good-story-abo…
It’s the first time, I read about IOC and didn’t understand their explanation..