IoC ako vsetci vieme je Inversion of Control design pattern, ktory tu uz
istu dobu existuje a dovolim si tvrdit exte pred samotnym springom
(http://en.wikipedia.org/wiki/Inversion_of_control). Spring sa tohto
patternu chytil a postavil nad nim svoj IoC kontainer, ktory okrem IoC
medzi beanmi poskytuje rozne sluzby.
Pod IoC chapem redukciu zavislosti medzi dvomi beanmi, tak ze jedna
pozna maximalne interface tej druhej a o samotne vytvorenie zavislosti
sa postara tretia osoba (kontainer).
to co popsal Fowler byl samozrejme jenom zaklad, bezne pozadavky pri
rogramovani jdou za nej.
Kedze IoC preslavil spring nakolko je nad nim postaveny, tak si viem
predstavit ze spring evangelisti chapu pod IoC to co maju v dokumentacii
springu v kapitole IoC uvedene.
ty veci, ktere jsem vyjmenoval pri programovani potrebujes, Fowler o
nich nepsal protoze to nebylo potreba. Rekneme, ze to jsou aplikacni
pozadavky.
- nemuzes pouzit factory metody ci Factory jako takove
Faktory metod je tiez design pattern spisany uz v 1995 GoF a v jave ho
mozem pouzit aj bez springu aj bez J2EE kontaineru
jinymi slovy ti EJB enforcuje navrh objektoveho modelu. Ja chci mit
Factory z nejakeho duvodu a zarooven chci, aby mi na ni IoC kontejner
delegoval *vytvareni* (pouze) objektu. V IoC EJB neresitelnmy problem...
Tenhle pozadavek je celkem bezny pokud zacnes dohromady integrovat tvuj
kod a kod nejakych knihoven tretich stran.
- vsechny tvoje objekty *musi* mit rozhrani tj. nemas moznost volby
To ze bean anotujem napriklad @Statefull a tym sa stava managovany
kontainerom povazujem skor za vyhodu pre samotny bean, pretoze moze
vyuzivat sluzby kontaineru. O hranici kedy ma byt bean manazovany
kontainerom som pisal v predchadzajucom maily.
to mluvis o necem jinem, o tom jak se stane objekt managovany. Ja rikam
ze v EJB musi mit kazdy managovany objekt rozhrani - opet EJB
enforcement do tvoji architektury
- zavislost nelze injectnout konstruktorem
Konstruktor injection naozaj J2EE kontainer nema. Dovodom asi bude ze je
menej pouzivana ako setter injection.
:-) cili EJB opet enforcuje to, ze nesmis pouzit konstruktor
- chybi extension pointy na strane IoC kontejneru (z pohledu Spring
BeanPostProcessor)
Lifecycle metody mozes v EJB definovat tiez (@PreCreate), ale to sme od
IoC design patternu daleko
ano to muzes, ale uz nemuzes napriklad rici co se ma stat s takhle
inicializovanym objektem. Predstav si, ze jej potrebujes nekam
zaregistrovat.
- nemuzes pouzit autowiring (velice uzitecne pro testy)
Pri developmente nepouzitelne - stracas prehlad
rpo vyjadreni klasickych zavislosti ne, ale pri testech je to vice nez
uzitecne. Je tak mozne, ze si nadefinujes test a IoC kontejner ti pak do
nej injectne testovany objekt.
public FooTest extends AbstractDependencyInjectionSpringContextTests {
private Foo foo;
public void testFoo(){
assert(foo.doSomething());
}
public void setFoo(Foo foo){
this.foo = foo;
}
}
- nemuzes definovat neprime zavislosti
Tomuto poslednemu bodu nerozumiem
mas dve beany A a B, ktere na sobe nejsou explicitne zavisle (nemaji
primou dependency) a potrebujes, aby bylo napriklad zarucene, ze IoC
kontejner nejdrive zinicializuje beanu B a teprve potom beanu A.
Ak teda porovnavame IoC, tak porovnavajme to co naozaj IoC je
http://www.martinfowler.com/articles/injection.html.
my (ja) porovnaveme prakticke pozadavky, ktere aplikace ma, pokud se
rozhodne IoC prijmout ;-). Vsechny ty pozadavky vychazeji z pripadu
uziti IoC v praxi a to v nasich produktech.
--
S pozdravem Roman "Dagi" Pichlik
/* http://www.sweb.cz/pichlik/ Blog pro kodery */
