If you have not come across it before read: PicoContainer - Five minute introduction. Simple, effective, easy.
In particular the article Getter-based Dependency Injection promotes a convincing AOP alternative.
I don't personally care for one approach ahead of the other as long as it conforms to the following guide:
- The container ready code must be as close to normal Java as possible. If you could use standard bean style class definitions, even better. This is where the getter article falters slightly because it depends on AOP.
- The container mechanism needs to be able to cope with different creational paradigms. This is where the getter approach is good because it uses a lazy, on demand injection - much more flexible.
- It has to be easy to conform to, otherwise people won't use it. If you are aleady an AOP house then the getter approach is easy to adopt, however if you prefer to use Proxies or not use AOP then you enter the dependency mire.
- It should not exclude using other containers in the same software.
- It has to be easy to use and package. Model based containers like Merlin can be difficult to get started.
Some things worth pointing out though...
If you implement the components in a getter injection kind of way then you could use them directly in a getter model. However, you can extend the same getter based implementations to wrap them in a setter or constructor injection implementation should you choose to use that style of container. So implementing in an AOP way does not require an AOP approach because all you are doing is separating the container integration functionality from the component.
A getter implementation can use velocity to generate whatever container integration is required. For testing, for pico (or nano), service locator, connector, soap, uddi or even for human intervention.
So what I say is write your components to use a getter-based dependancy injection framework, and extend it to fit your chosen container paradigm.
No comments:
Post a Comment