V poslední době se hodně hovoří o JBoss Seamu - píší se o něm články (1, 2, 3), přednáší se o něm, u nás v práci se vedou diskuze, zda ho použít nebo ne. Mě už to prostě nedá, abych zapřemýšlel veřejně, protože bych moc rád moje názory zkonzultoval s okolním světem.
Ještě než se pustím do "přemýšlení", tak musím poznamenat, že jsem hodně ovlivněný Springem - mám tu technologii rád, nikdy mě nezklamala, ztotožňuji se s názory lidí ze SpringSource. Mám také rád Javu, protože mám možnost plné kontroly nad aplikací, když chci napsat výkonnou, škálovatelnou a robustní aplikaci.
Také musím napsat, že nemám žádnou větší zkušenost se Seamem, pouze jsem si zkoušel a procházel nějaká dema.
Co se mi na Seamu líbí?
- výborně integruje (a opravuje) technologii JSF a pokud dnes někdo chce používat JSF, tak asi určitě se Seamem.
- Seam framework integruje spoustu technologií dohromady v jeden kompaktní celek.
- Seam považuji nejsilnější v prezentační vrstvě, hlavně se mi líbí možnost využití a integrace AJAXových komponent.
- Nemůžu nezmínit rychlost vývoje, potažmo náklady na vývoj aplikace.
Co se mi na Seamu nelíbí?
- velice mi jsou blízká "čistá", flexibilní řešení, protože člověk nikdy neví (lépe řečeno zákazník nikdy neví). Z tohoto pohledu se mi Seam moc nelíbí - z vlastní zkušenosti vím, že hodně často je potřeba ještě jedna vrstva (Facade) mezi kontrolerem a aplikační vrstvou. Dnes je in, že vše musí být POJO, ale pokud POJO má na sebe navěšeno spoustu anotací, které mi zabraňují v testování, které mě vážou k nějakému řešení, tak už to není POJO.
- Všechno kromě snad prezentační vrstvy (ale i zde by se dalo spekulovat) jde udělat stejně dobře nebo lépe pomocí Springu. Mám na mysli zejména možnosti integrace s dalším knihovnami, možnosti konfigurace, možnosti testovatelnosti apod.
- Spring security (dříve Acegi framework) považuji za nejlepší open-source řešení pro zajištění bezpečnosti aplikací. Seam pěkně zapojil Drools, ale i tak se to nedá srovnávat, hlavně co se týče flexibility a možností.
- Vše je konfigurováno pomocí anotací. Někdo je má rád, někdo ne. Já jak kdy, takže mi tu chybí možnost volby. Např. konfigurace scheduleru přes anotace v Seamu mi přijde celkem hrozná.
- Kompaktnost řešení je negativně vyvážena omezenou možností použití řešení třetích stran.
Co říci závěrem
V žádném případě nemohu říci, že Seam je špatný framework, protože to není pravda. Seam udělal resp. udělá velkou službu Java světu, protože dokáže přitáhnout lidi, kteří chtějí dělat malé až středně velké webové aplikace bez nějaké větší aplikační logiky v pozadí, kteří ale nechtějí nebo mají strach se prokousávat tolika technologiemi, které je potřeba pochopit a naučit se.Já ale (snad) už začátečník v Javě nejsem, potřebné technologie znám, nerad vytvářím GUI, spíše mě zajímá pozadí aplikace, píši malé, středně velké až velké aplikace, které nepracují pouze s databází, které mají mnohdy složitou aplikační logiku, které mají být výkonné, robustní... A proto tedy nemám rád Seam.
Příspěvky
15 komentářů:
Mně osobně se zatím jeví jako slibný kandidát pro webové aplikace komponentový framework Wicket. Zákazník ne vždy chce úplně modelový případ aplikace, takže ani Seam nás podstatné většiny vývojového břemena nezbaví, a na druhou stranu v případě větších aplikací se vyplácí "reuse" komponent a Wicket slibuje přímočarou možnost tvorby vlastních komponent přesně podle potřeby. Navíc lépe zapojím do vývoje webové designéry, neboť Wicket používá standardní HTML.
Je pravda, že v poslední době o Wicket slyším čím dále více a většinou jen samou chválu. Tak to mi nezbývá nic jiného, než to vyzkoušet :).
Je jasne, ze ne kazdemu bude Seam vyhovovat.
Ale zpet.
1. Co se tyce te prvni nevyhody. Spis je to preci o tom, jak danou aplikaci pisi. Zda primo v Seam komponentach pisi aplikacni logiku, je jasne, ze tim snizuji moznost rozsireni. Na druhou stranu, proc nechapat Seam komponenty jen jako cisty kontroler nad aplikacni logikou, ktera je uplne jinde a o zadnem Seam nema ani paru?
2. Spring moc neznam, ale nechapu jakou konfiguraci mas na mysli. Me naopak prislo, ze v components.xml mohu udelat vse, co v anotacich, ba dokonce i vice. Jako konfiguracni zdroj mi prijde, ze je vice nez dostacujici.
3. Drools mi prijdou naprosto uzasne. Opet, je moznost jit "simple", kde pujde jen o role, nebo pres drools, kde jde o akce k opravneni. Jiste je to vice, nez samotna "security featura" v cistem J2EE.
4. Stale existuje xml. A v xml lze v Seamu psat. Pravdou je, ze by to byla asi velka onanie :)
Ten, kdo anotace nesnasi, ci je nerad vidi, tak pro toho jiste Seam neni. Myslim, ze stejne tak (mozna i vic) bude nenavidet Web Beans.
5. To si myslim, ze neni pravda. Seam sice spojuje jsf + EJB (ci Spring), ale nijak me nekonzervuje do toho, co je backendem daneho frameworku. Jedine omezeni se tyka ve webove prstve, kde primarne lze pouzit opravdu jen JSF, vsechny ostatni veci jsou stale "testing".
Zdravím,
myslím, že porovnávat Spring a Seam je jako říci, že máme paměti RAM a ROM.
Spring dělá více věcí než Seam. Naopak pokud je porovnáme jako webové frameworky, tak Spring MVC zas tak úžasný není.
Pokud nechci dělat webovou aplikaci, tak nemůžu použít Seam (teda můžu, ale nikomu bych to nepřál :-).
Myslím, že drools a acegi mají trošku jiný cíl - acegi definuje různá pravidla pro přihlašování pomocí různých technologií, autorizaci, ...
Kdežto drools je nástroj pro zápis přístupových práv. Proto porovnání těchto nástrojů je trošku "pracnější".
Určitě platí, že lze používat Spring pro komponenty a současně Seam jako webový framework.
Tohle je snad nevtipnejsi nazor:
Co se mi na Seamu nelíbí?
Všechno ... jde udělat stejně dobře nebo lépe pomocí Springu.
Nejsem moc rád, že to vyznělo, že porovnávám Spring vs. Seam, takto jsem to nemyslel. Když jsem psal "Všechno kromě snad prezentační vrstvy", tak jsem myslel pouze ty věci, které umí Seam, protože samozřejmě Spring framework má jiné zaměření, jiný rozsah.
Drools znám již nějaký čas, ale použití v Seamu mi přijde úplně úžasné a pro potřeby Seamu (asi) plně dostačující, ale jak bylo uvedeno, Acegi má zase o dost větší rozsah - co když potřebuji autentikaci oproti LDAPu, co když potřebuji zapojit CAS atd.?
Celkově se to hodně těžko porovnává, stejně jako Seam jako JSF vs. Spring MVC. Oba dva přístupy jsou rozdílné a už jenom díky tomu mají své výhody nebo nevýhody a je jedno jaká bude implementace.
Já asi beru Seam moc podle toho, jak je prezentovaný, jak vypadá v demech - jeden balíček kompletního řešení pro vaše aplikace. Spojení Seam a Spring mi přijde hodně zajímavé - Seam se postará o "vršek" aplikace, Spring udělá vše ostatní. Pak si myslím, že spojíme to nejlepší z obou světů.
Ještě poznámečka :} - cílem článku nebylo vyvolat nějaký laciný flame. Jde mi hlavně o porovnání mých argumentů s názory ostatních. Za některými věcmi si stále stojím, za některými už tolik ne. Každopádně děkuji.
Petre, lepsi by bylo porovnat Spring Web Flow + neco (JSF, Spring MVC, Struts) vs. JBoss Seam. Ja jsem na tohle tema vyvolal diksusi viz http://www.sweb.cz/pichlik/archive/2007_10_21_archive.html#2953300892787564807.
a co tahle spring dohromady se seamem? sila springu a featurky seamu. Pouzite proste spring na to co umi a na seamu nechate "jen" starost o prezentacni vrstvu.
Ja osobne kdybych chtel delat aplikaci s JSF, tak pouziju Seam+spring protoze se Seamem je vyvoj JSF aplikace jednoduchy a rychly.
Kdybych nechtel JSF tak to namastim asi ve Spring + Spring MVC :-)
Jen chci dodat ze se Springem zkusenosti mam relativne velke, se Seamem jsem delal 1 aplikaci. Ale seam + spring jsem spolecne nezkousel. Jen jsem se koukal na examples v distribuci seamu a zda se me moje tvrzeni jako logicke :-)
Ještě poznámečka :} - cílem článku nebylo vyvolat nějaký laciný flame...
Ale no tak Petře :-) ... jinak musím souhlasit s Milanem Vichem (mnohokrát jsme to přece probírali), proto tenhle článek musím považovat alespoň z části jako jasný flame :-)
Já vím Martine, že jsme to spolu hodně probírali, ale tam jsme předpokládali (nebo alespoň já), že JSF je jasná věc.
Já si teď s tím JSF moc jistý nejsem, a když dosud není jiná alternativa v Seamu, tak pro mě malinkato padá jako celek. Bohužel sám pořádně ještě nemám jasno, co místo toho - Wicket, Spring MVC, Spring Web Flow?
Nerozumim argumentum, proc použití jedné technologie (seam) vylučuje použití jiné technologie (spring). V poslední době se ukazuje, že právě integrace technologií, které byly vytvářeny nezávisle na sobě, rapidně zvyšuje použitelnost takového řešení (seam).
Nějakou dobu si pohrávám z myšlenkou integrace Spring Web Flow + GWT + Spring MVC (případně jiný MVC/template framework). Může tomuto spojení něco zabránit?
Je pravda, že ten článek byl tak trochu pojat Seam vs. Spring, ale to je asi jen kvůli tomu, že Spring hodně používám a proto hodně řeším, zda jiná řešení řeší určité věci lépe nebo ne.
Jinak už to zde i zaznělo - plně souhlasím se spojením Seam a Spring.
Nemáš rád Seam? Na základě prohlídky dema? :) Myslím, že je trochu předčasné zošklivovat si technologii se kterou - jak sám píšeš - nemáš skoro žádné praktické zkušenosti. Co když ji budeš v budoucnu nucen používat? Budeš to dělat od začátku s odporem tzn. špatně? IMHO by bylo lepší hodnotit Seam třeba po třetím projektu, který v něm uděláš.
O integraci Seamu a Springu vyšel pěkný článek na Javaworldu - první a druhý díl.
Okomentovat