Zdravim, my pouzivame tiez myslienku cislo jedna, teda dotazy vo forme in obmedzeni. Tie in obmedzenia, kym sa nejedna o tisicky idciek su uplne vpohode.
Ale mame aj vinimku, mame totiz modul, ktory potrebuje citat udaje z mnohych modulov naraz a ma vselijake svoje obmedzenia. Konkretne tento modul exportuje data do ineho systemu a bol navrhnuty genericky. S pomocou malej konfiguracie sa da rozsirit export, niekedy vsak to nejde, lebo su tam nejake podmienky, takze sa napise sql. Exportuju sa cele siete objektov. Ak by to malo byt modularne, tak kazdy modul by mal exportovat svoje data, svoju siet. No to by chcelo ovela viacej premysleny navrch, kedze exportovane udaje nie su cela DB, ale cielom je exportovat mininum dat a dba sa na performanciu, robia sa teda aj joiny medzi modulmi. Cize kedze tento Export robi iba citanie, tak ma dovolene sahat do lubolnej tabulky. Ale tym ze modul ma vsetky query u seba, vznika aj duplicita niektorych dotazov, no nie je toho vela. Zaver z tohoto prikladu znie, ze moze nastat pripad, ked by sa implentacia stazila resp. aj znizila performancia pri dodrzani modularneho dizajnu, ak by sa dobre nepremyslel dizajn. 2010/9/2 Ing. Jan Novotný <novotn...@gmail.com> > 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 <m...@alis.cz> > > 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 >> >> >
