Správy bych se vůbec nebál. Je to úplně stejně jako se správou oddělených aplikací: vždy záleží na rozhraní jednotlivých modulů.
Lze to udělat úplně nezávislé (pouze odkazy v UI (linky, menu)) bez sdílení dat, lze to udělat totálně provázané, záleží na chuti a libovůli architekta. Výhoda tohoto monolitu je v tom, že se minimalizuje nutnost copy&paste správy různých uživatelských nastavení atd... Budeš-li při vývoji používat nástroj, které má v sobě integrovanou podporu pro správu subprojektů (Eclipse, Idea, maven,...), budeš to mít hezky oddělené a přes závislosti můžeš importovat sdílený kód a jednotlivé reference. Pokud jde o proti, tak to je "nepřipravenost" na rozdělení na víc serverů - to ale při rozumném návrhu není problém. Potom je další proti horší možnost znovupoužitelnosti: u libovolné vzdálené komunikace je přeci jen snadnější zavolat stejné rozhraní z více míst než u lokálního volání. On Thursday 13 April 2006 15:31, Jakub Příkazský wrote: > 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,... -- Oto 'tapik' Buchta, [EMAIL PROTECTED] Senior Engineer, Systinet, Mercury Division http://www.mercury.com -- Oto 'tapik' Buchta, [EMAIL PROTECTED] http://www.buchtovi.cz ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
