Re: Spolupráce aplikací

[Jakub Příkazský]

Toto řešení se mi líbí z toho důvodu, že bych se nemusel zabývat spoluprací mezi aplikacemi. Trochu mě ale děsí, jak takovýto monolit udržovat ve funkčním stavu. Obávám se, že se v tomto případě velmi špatně hlídá vývoj aplikací. A pokud mám pravdu, je možné se tomutu problému vyvarovat? Ačkoliv přiznávám, že nejsem schopen tak daleko dohlédnout a moje obava může být zbytečná. Dokážete najít argumenty pro a proti? Zdá se, že na tuto otázky existují různé názory a záleží především na konkrétním účelu aplikací viz. příspěvek Petra Burdika. díky Jakub Oto 'tapik' Buchta wrote: On Thursday 13 April 2006 10:22, Martin Kuba wrote: Jakub Příkazský wrote: Pokud budu mít například několik aplikací (evidencí) - app1,..,appN (cca 5-20ks) a každý zákazník, bude chtít jenom některé, pak mi přijde rozumné je provozovat odděleně.Nelíbí se mi myšlenka, že by měl existovat jeden aplikační monolit, v němž bych musel určovat kterou aplikaci bude zákazník využívat. Proto mě zajímá řešení problému, jak zajistit jejich vzájemnou komunikaci a spolupráci. Ačkoliv se mohu mýlit a naopak je "monolitická" cesta vhodnější. Uvažuji správně? Tohle mi prijde jako pekny kandidat na customizaci, tj. udelate monolit zahrnujici vsechny aplikace, a v konfiguraci pro konkretniho zakaznika urcite, ktere z nich se daji pouzivat. Mate jednu aplikaci, kterou musite udrzovat, instalace u zakazniku se lisi jenom konfiguraci. Souhlas. A samozrejme je tady moznost mit kazdou "aplikaci" v samostatnem jaru (stejne to budou asi samostatne moduly, ne?) a proste a jednoduse to jenom vzdy prebalit. A navic one konfiguraci by slo urcite pomoci tak, ze se zavola Class.forName() na jednu vyznamnou tridu z kazdeho modulu a automaticky si nastavit konfiguraci podle nalezenych trid. Idealane tak, ze ona vyznamna trida bude konfigurator, ktery rageistruje ruzne listenery, renderery, graficke prvky,...