Ahoj,
my jedeme na modulárním systému asi 2 roky (s tím rozdílem, že nemáme
OSGI, ale jen zřetězené aplikační konexty Springu na stejné classpath -
nicméně už to k zavedení modulárnosti stačí). Řešili jsme stejný problém a
obávám se, že neexistuje ideální řešení. Základní pravidlo spočívá ve
správném "řezu" modulů - každý by měl mít jednoznačnou odpovědnost a funkci.
Moduly by se měly vzájemně doplňovat spíš než ve funkcionalitách překrývat.
Prostě příliš malé moduly nejsou dobré, protože mají potom mnoho závislostí
ven, velké moduly také nejsou dobré, protože se tím zase snižuje jejich
použitelnost. Na správném řezu funkcionalitou prostě záleží hodně.
Pokud by jeden modul sahal do dat jiného modulu přímo a nikoliv přes jeho
API povede toto porušení zapouzdřenosti k: svázanosti (couplingu) těchto
dvou modulů, zhoršení testovatelnosti, problém se samostatným rozvojem
modulů (vždy se na ně bude muset pohlížet jako na nějaký provázaný celek).
My jsme došli ke dvěma možným technikám v těchto případech (naštěstí těch
případů není zase až tak moc).
1) obětování výkonu - tj. každý modul udržuje pouze svá data a pokud z
nějakého důvodu potřebuje vrátit či pracovat s daty jiného modulu, jde přes
jeho API - tím se ale samozřejmě nedá využít JOINů a platíme výkonem. Tyto
mezimodulové "dotazy" se alespoň snažíme optimalizovat na metodách API tím,
že tam máme metody pro hromadné načítání dat - např. List<Data>
getDataById(Integer... id), která může všechna potřebná data načít
jednorázově přes WHERE id in (...)
2) porušením normální formy db - kromě přímého volání mezi moduly na úrovni
API máme ještě jednu formu komunikace postavenou na "observer patternu",
která vychází ze Springu, tj. moduly v důležitých okamžicích své
funkcionality publikují tzv. eventy do systému, na které pak mohou reagovat
listenery v jiných modulech. Tímto způsobem je možné distribuovat některá
důležitá (i agregovaná) data do zbytku systému. Uvedu příklad - máme tzv.
hodnotící modul, který umožňuje hodnotit libovolný obsah kdekoliv (např. ve
formě hvězdiček na nějaké škále), tento modul samozřejmě o obsahu samotném
nic neví - naopak jiný modul, který spravuje daný obsah (třeba články) chce
při vracení článku vracet aktuální hodnotu průměrného hodnocení. Hodnotící
modul vždy po přepočtení aktuálního hodnotícího čísla po daný obsah vyhodí
událost do systému, na kterou může kterýkoliv jiný modul naslouchat. Modul
starající se o články tuto událost odchytí a k článku si uloží dodatečný
údaj o aktuálním hodnocení (již vypočtený, hotový k zobrazení). Tímto
způsobem je porušena normální forma - jeden údaj je v DB uložen 2x, nicméně
data jsou potom již hezky po ruce (bez výkonnostní penalizace) a nedochází k
narušení zapouzdřenosti modulů - jeden může bez problému fungovat bez
druhého, pokud běží oba - spolupracují.
Pokud existuje ještě nějaký jiný způsob komunikace rád se jej dozvím.
Jak říkám, ani jedna z výše uvedených praktik není úplně ideální, ale na nic
lepšího jsme za ty roky nepřišli :(.
Honza
--
--------------------------------------------------------------
Ing. Jan Novotný
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
http://blog.novoj.net
Myšlenky dne otce Fura
--------------------------------------------------------------
2010/9/1 David Mach <[email protected]>
> Zdravím všechny!
>
> V naší firmě jsme doposud vyvíjeli klasické aplikace na jedné classpath
> (typu "vidím vše, volám vše, využívám vše", čili občas pěkná prasárna). Nyní
> vyvíjíme novou modulární aplikaci postavenou na OSGi, přičemž naše původní
> vize byla ta, že jednotlivé moduly mezi sebou budou komunikovat výhradně
> prostřednictvím API. To by ale například znamenalo, že pro získání dat z
> modulu A (která potřebuji pro SQL dotaz v modulu B) budu muset nejprve volat
> nějakou metodu z API modulu A, získat ta data a teprve posléze budu moci
> složit SQL dotaz v modulu B. Z této představy ovšem vstávají některým
> kolegům hrůzou vlasy na hlavě a horují pro to, abychom se drželi klasické
> cesty, kdy data z tabulek náležejících k modulu A budeme získávat pomocí
> JOINů.
>
> Chci se tedy zeptat přítomných zkušenějších vývojářů na to, zda je původní
> vize správná a také na zkušenosti z implementace. Zajímá mě také rozdíl ve
> výkonu aplikace při použití API vs JOIN...
>
> Vřelé díky předem!
>
> David Mach
>
>
