Roman Pichlik wrote: Myslim si ze prave IoC je v EJB dotiahnute.
no tak to neni ani omylem. 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). 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. - 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 - 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. - zavislost nelze injectnout konstruktorem Konstruktor injection naozaj J2EE kontainer nema. Dovodom asi bude ze je menej pouzivana ako setter injection. - 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 - nemuzes pouzit autowiring (velice uzitecne pro testy) Pri developmente nepouzitelne - stracas prehlad - nemuzes definovat neprime zavislosti Tomuto poslednemu bodu nerozumiem Ak teda porovnavame IoC, tak porovnavajme to co naozaj IoC je http://www.martinfowler.com/articles/injection.html. Martin Krajci
