Article:  |
Five Things I Love About Spring | |
| Subject: | What is a dependency again? | |
| Date: | 2005-05-11 21:28:25 | |
| From: | shmert | |
|
It seems that there should be a glossary of terms for this article, I got a little lost with the terminology. Or perhaps some examples might be helpful. What does the interceptor intercept? Why exactly do we need one? And what is all this stuff, perl?: com.springbook.RentABike.transferReservation= PROPAGATION_REQUIRED,-ReservationTransferException com.springbook.RentABike.save*=PROPAGATION_REQUIRED com.springbook.RentABike.*=PROPAGATION_REQUIRED,readOnly
|
||
Showing messages 1 through 2 of 2.
-
What is a dependency again?
2005-05-12 07:35:09 barryhawkins [Reply | View]
If dependency injection and transaction interception are foreign to you, it might be good to check out the Spring documentation from the website and/or some of the articles that focus more on introducing the concepts used by Inversion of Control lightweight containers. The short answers to your questions would be:
1.) The interceptor intercepts calls to specific methods, listed in the value tag shown in the XML excerpt you guoted. The values to the right of the equals sign specify what sort of transactional attributes are assigned to the method(s) specified. Figure 1 in item 2 of the article is a pretty good diagram of that.
2.) You mostly need the interceptor mentioned in the article if you want to enable transactions for your DAO operations, which is usually the case.
3.) The format of the block you quoted is the standard Java(TM) proporties format of key/value pairs, delimited by the equals sign and newlines. That is contained within the XML tag <value>
P.S. Even geniuses have to RTM sometimes ;-)
You can do a Google search to learn more on this topic, but in a nutshell, it says that your high level important business classes shouldn't be dependent upon lower level (less important) classes. You may have heard the terms "tightly coupled" and "loosely coupled" describing this same type of thing. Sometimes the dependencies are even cyclical, which is the worst condition (though it's acceptable, as is tight coupling, when the classes involved truely are very closely related and expected to always be used together. Normally, you'd expect these classes to exist in the same package.)