Ja by som sa ho opytal preco :). Je jasne ze nie vzdy je vhodne delenie
na vrstvy, zalezi od aplikacie, ale vrstvy su odolne voci zmene
poziadavkam. Lenze ak si spomenie napr na SOA, tak to je este odolnejsia
architektura voci zmene poziadavkam. A ak sa predpoklada ze sa
poziadavky budu velmi menit, alebo su nejasne, tak by som okrem navrhu
super architektury rozmyslal o prototype alebo extremnom programovani.
Jiří Kotal wrote / napísal(a):
V tomto případě šlo spíše o jednotlivé vrstvy systému, jednak z hlediska
třívrstvé architektury a jednak vnitřní členění na další subvrstvy. Zmíněný
architekt zastává názor, že pokud se předpokládají časté změny v
požadavcích, je výhodnější vůbec členění na subvrstvy nezavádět. Osobně si
myslím, že naopak vhodné "vrstvení" aplikace přispěje ke snadnější realizaci
změn.
Jirka
-----Original Message-----
Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim
rozhranim.
Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musí
menit nejake "vnitrni API", tak je asi neco spatne. Mozna je pes zakopany
nekde v nepochopeni tohoto rozliseni?
http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi
(Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme
s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/
)
A nebo to API neni vubec API, ale jen nejaky implementacni kod?
Ondra Nekola
