Wymagania pozafunkcjonane czyli jaka architektura

Poza wyma­ga­nia­mi funk­cjo­nal­ny­mi, poda­je­my tak zwa­ne wyma­ga­nia poza-funk­cjo­nal­ne. Mają one, mię­dzy inny­mi, waż­na rolę do speł­nie­nia. Jaką?

Najpierw cytat:

Technologia klient/serwer jest zależ­na od komu­ni­ka­cji pomię­dzy poszcze­gól­ny­mi kom­pu­te­ra­mi. Sieci LAN i WAN sta­ją się znacz­nym wydat­kiem oraz wyma­ga­ją dużych nakła­dów pra­cy w związ­ku z zarzą­dza­niem nimi. Co wię­cej, zmia­na wer­sji opro­gra­mo­wa­nia na wie­lu kom­pu­te­rach, co szcze­gól­nie widocz­ne jest w przy­pad­ku prze­twa­rza­nia roz­pro­szo­ne­go, sta­je się istot­nym pro­ble­mem. Wielokrotnie dzia­ły IT zasta­na­wia­ją się nad przej­ściem na struk­tu­rę Internet/Intranet w celu roz­wią­za­nia tego pro­ble­mu. (Wstęp do ERP – tech­no­lo­gia u pod­wa­lin przedsiębiorstwa).

Pomijając pro­sto­tę” tego tłu­ma­cze­nia, chcę zwró­cić uwa­gę na waż­ną rzecz: bar­dzo duże znacz­nie ma archi­tek­tu­ra sys­te­mu, nie­ste­ty wie­lu pro­du­cen­tów ukry­wa zasto­so­wa­ną tech­no­lo­gię i archi­tek­tu­rę. Jedną z przy­czyn jest to, że są to nie raz tech­no­lo­gie rodem z lat 90-tych a bywa, że nawet wcze­śniej­sze. Jedną z takich sta­ro­ci” jest archi­tek­tu­ra client-server (tak zwa­ny gru­by klient). Innym typem dino­zau­ra” tech­no­lo­gicz­ne­go jest two­rze­nie opro­gra­mo­wa­nia, w któ­rym logi­ka biz­ne­so­wa jest w jakiejś czę­ści w pro­ce­du­rach wbu­do­wa­nych bazy danych (w rozu­mie­niu kon­kret­ne­go tak zwa­ne­go moto­ra SQL bazy).

Jaki mamy wybór?

Zanim powie­my sobie o wybo­rze, kil­ka słów na temat kla­sycz­nej trój­war­stwo­wej archi­tek­tu­ry jako fun­da­men­cie dal­szych roz­wa­żań. Struktura taka wyglą­da następująco:

Architektura trójwarstwowa

Mamy tu trzy war­stwy: Warstwa pre­zen­ta­cji, czy­li kom­po­nent odpo­wie­dzial­ny za wyświe­tla­nie infor­ma­cji na ekra­nie użyt­kow­ni­ko­wi i ich przyj­mo­wa­nie. Warstwa logi­ki apli­ka­cji podzie­lo­na na Logikę dzie­dzi­no­wą (część spe­cy­ficz­na dla dzie­dzi­ny pro­ble­mu, tu są np. fak­tu­ry, spo­sób nali­cza­nia podat­ków, raba­tów itp. ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne) oraz Logikę poza-dzie­dzi­no­wą (wydaj­ność, nie­za­wod­ność, bez­pie­czeń­stwo, inte­gra­cja z inny­mi apli­ka­cja­mi itp.). Najniżej jest war­stwa Utrwalania, coraz czę­ściej w para­dyg­ma­cie obiek­to­wym pomi­ja­na na tym pozio­mie abs­trak­cji (utoż­sa­mia­na z reali­za­cją wyma­gań poza-funk­cjo­nal­nych zwią­za­nych z zacho­wy­wa­niem informacji).

Praca w sie­ci wie­lu użyt­kow­ni­ków to wie­lo­do­stęp (wie­le sta­cji robo­czych korzy­sta z jed­ne­go serwera):

Wielodostęp

Gruby klient

Gruby klient to archi­tek­tu­ra w któ­rej każ­dy użyt­kow­nik ma na swo­im lokal­nym kom­pu­te­rze nie tyl­ko war­stwę pre­zen­ta­cji ale tak­że całą logi­kę apli­ka­cji. Każde takie sta­no­wi­sko komu­ni­ku­je się z ser­we­rem danych:

Architektura Gruby klient

Do powyż­szej archi­tek­tu­ry odno­szą się głów­ne uwa­gi o wadach z cyta­tu na począt­ku. Cechy archi­tek­tu­ry po lewej stro­nie: kosz­tow­ne sta­cje robo­cze (muszą, każ­da, udźwi­gnąć całe opro­gra­mo­wa­nie), kosz­tow­na admi­ni­stra­cja (nie­zgod­ność wer­sji na sta­cjach robo­czych może pro­wa­dzić do kra­chu sys­te­mu), kosz­tow­ne mody­fi­ka­cje (tak­że z uwa­gi na wyma­ga­ną zgod­ność opro­gra­mo­wa­nia na sta­cjach robo­czych), bar­dzo duże wyma­ga­nia na pasmo i nie­za­wod­ność sie­ci (duże trans­fe­ry danych pomię­dzy sta­cja­mi robo­czy­mi i ser­we­rem, zerwa­nie połą­cze­nia powo­du­je blo­ka­dy dostę­pu do danych) powo­du­ją, że pra­ca w sie­ci roz­le­głej tery­to­rial­nie może być wręcz nie­moż­li­wa (wte­dy wyma­ga powie­la­nia insta­la­cji w każ­dej loka­li­za­cji i syn­chro­ni­za­cji danych, kolej­ne nie­ma­łe kosz­ty). Pewną odmia­ną jest wariant po pra­wej stro­nie, gdzie część logi­ki apli­ka­cji jest umiesz­czo­na na ser­we­rze danych (kon­kret­nie bazy danych), powo­du­je to nie­co zmniej­szo­ny ruch w sie­ci ale dodat­ko­wo kom­pli­ku­je wszel­kie roz­sze­rze­nia funk­cjo­nal­no­ści i upgra­de oraz prak­tycz­nie unie­moż­li­wia zmia­nę (wybór) pro­du­cen­ta bazy danych. Duże kosz­ty tej archi­tek­tu­ry dodat­ko­wo potę­gu­je wymóg wyku­pie­nia licen­cji na bazę danych dla każ­de­go użytkownika.

W więk­szo­ści przy­pad­ków tej archi­tek­tu­ry, logi­ka biz­ne­so­wa (dzie­dzi­no­wa) nie jest sepa­ro­wa­na od resz­ty, w efek­cie dodat­ko­wo wszel­kie pra­ce dosto­so­waw­cze są bar­dzo kosz­tow­ne (inge­ren­cja w całą aplikację).

Architektura internetowa – cienki klient

Taką nazwę od pew­ne­go cza­su nada­je się archi­tek­tu­rze opar­tej na dostę­pie do apli­ka­cji z pomo­cą prze­glą­dar­ki WWW:

Architektura Cienki klient

Powyższa archi­tek­tu­ra prak­tycz­nie nie ma żad­nej wady poprzed­nie­go roz­wią­za­nia. Dodatkowo baza danych licen­cjo­no­wa­na jest z regu­ły na apli­ka­cję a nie na każ­de­go użyt­kow­ni­ka (czy­li jest taniej). Stosując tak zwa­ne meto­dy i archi­tek­to­nicz­ne wzor­ce obiek­to­we (naj­po­pu­lar­niej­szy to MVC: Model, View, Controller) sepa­ru­je się kom­po­nent logi­ki biz­ne­so­wej od logi­ki ste­ro­wa­nia apli­ka­cją. W efek­cie dosto­so­wa­nie apli­ka­cji nie pole­ga na kosz­tow­nym mody­fi­ko­wa­niu logi­ki apli­ka­cji, doda­je się i inte­gru­je nie­za­leż­ny kom­po­nent Logiki biz­ne­so­wej, co dodat­ko­wo pozwa­la zacho­wać sepa­ra­cję praw autor­skich do kodu logi­ki biz­ne­so­wej (know-how fir­my). Korzyścią takiej archi­tek­tu­ry jest tak­że moż­li­wość łatwe­go doda­wa­nia moż­li­wo­ści dostę­pu z innych niż kom­pu­ter PC, urzą­dzeń (smart­fo­ny, table­ty, itp.) gdyż wyma­ga to wyłącz­nie nowej war­stwy pre­zen­ta­cji, logia pozo­sta­je spój­na na serwerze.

Kolejna korzyść to łatwa inte­gra­cja z inny­mi apli­ka­cja­mi. Oprogramowanie w tej archi­tek­tu­rze ukry­wa” dane, dostęp do nich jest wyłącz­nie przez Logikę apli­ka­cji za pośred­nic­twem tak zwa­nych API (inter­fejs pro­gra­mi­stycz­ny) meto­da­mi zna­ny­mi w sie­ci WWW, uni­ka­my kosz­tow­nych i ryzy­kow­nych łączy bez­po­śred­nich do baz danych (niska pra­co­chłon­ność inte­gra­cji, bar­dzo wyso­kie kosz­ty utrzy­ma­nia i rozwoju).

W efek­cie reko­men­do­wa­na archi­tek­tu­ra mogła by wyglą­dać tak:

Rekomendowana architektura aplikacji

Zalety: niskie kosz­ty utrzy­ma­nia sys­te­mu i infra­struk­tu­ry, sepa­ra­cja logi­ki biz­ne­so­wej (dzie­dzi­no­wej) dedy­ko­wa­nej od kupio­nej”, łatwość i niski koszt upgra­de, pra­ca z pomo­cą prze­glą­dar­ki WWW, łatwa inte­gra­cja z inny­mi apli­ka­cja­mi, łatwość pra­cy w sie­ci lokal­nej i roz­le­głej (w tym łatwy zdal­ny dostęp z dowol­ne­go cudze­go kom­pu­te­ra). To tyl­ko głów­ne korzyści.

Wymagania pozafunkcjonalne

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.

Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

[2015]

Polecam poga­dan­ke M.Fowlera na temat roli architektury:

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. jacek2v 1 kwietnia 2014 at 18:38

    Z mojej prak­ty­ki wyni­ka, że MVC nie nada­je się do reali­za­cji suge­ro­wa­nej archi­tek­tu­ry cien­kie­go klien­ta”. Głównym powo­dem jest trud­ność w odse­pa­ro­wa­niu logi­ki apli­ka­cji od pro­ce­du­ral­nej imple­men­ta­cji wywo­łań”, czy­li kodu nie­zbęd­ne­go, aby wszyst­ko zadzia­ła­ło, ale nie­istot­ne­go z punk­tu widze­nia logi­ki apli­ka­cji. Znacznie lep­sze jest bez­po­śred­nie imple­men­to­wa­nie w kodzie DDD (Domain Driven Design) lub BDD (Behavior Driven Development).

    • Jaroslaw Zelinski 1 kwietnia 2014 at 23:03

      DDD to wzor­ce Modelu”.… Sugerowana archi­tek­tu­ra to View” po stro­nie klien­ta i resz­ta po stro­nie ser­we­ra. Co to jest pro­ce­du­ral­na imple­men­ta­cja wywołań”?

  2. Jaroslaw Zelinski 2 kwietnia 2014 at 22:14

    Przykład apli­ka­cji typu gru­by klient”: SAP Business One, BPSC, …

  3. jam 16 czerwca 2014 at 20:59

    dla­cze­go dino­zau­rem tech­no­lo­gicz­nym” nazy­wasz apli­ka­cje z czę­ścią logi­ki prze­cho­wy­wa­ną w pro­ce­du­rach wbu­do­wa­nych baz danych. Mógłbyś to jakoś rozwinąć?

    • Jaroslaw Zelinski 16 czerwca 2014 at 22:23

      W dużym uprosz­cze­niu: to bar­dzo kosz­tow­ny (koszt wpro­wa­dza­nia zmian) i archa­icz­ny spo­sób na prze­cho­wy­wa­nie logi­ki biz­ne­so­wej, w 100% uza­leż­nia od kon­kret­nej imple­men­ta­cji moto­ra SQL. Rozbudowane apli­ka­cje sta­ją tak trud­ne i kosz­tow­ne do utrzy­ma­nia. Tak zaim­ple­men­to­wa­na logi­ka jest nie­po­dziel­na, trud­no o podzie­le­nie jej na odse­pa­ro­wa­ne, roz­łącz­ne modu­ły. Język pro­ce­dur wbu­do­wa­nych jest trud­ny do zarzą­dza­nia przy rosną­cej ilo­ści linii kodu”. Wszystkie sys­te­my ERP, z któ­ry­mi mia­łem kon­takt, zbu­do­wa­ne w opar­ciu o tę meto­dę imple­men­ta­cji, były bar­dzo kosz­tow­ne w roz­wo­ju i mody­fi­ka­cji, opro­gra­mo­wa­nie kom­po­nen­to­we, zbu­do­wa­ne meto­da­mi obiek­to­wy­mi (ale to nie to samo co napi­sa­ne w języ­ku obiek­to­wym!) z regu­ły daje niż­sze kosz­ty roz­wo­ju. To tak­że kon­se­kwen­cja sto­so­wa­nia baz w mode­lu rela­cyj­nym, trud­no taką bazę mody­fi­ko­wać w żyją­cym” sys­te­mie (np. sys­tem IFS). Co cie­ka­we, takie imple­men­ta­cje są zawsze droż­sze (a mam sta­ły kon­takt z ofer­ta­mi w odpo­wie­dzi na te same zapy­ta­nia). Nie jest to tyl­ko moja opi­nia, śle­dząc lite­ra­tu­rę z obsza­ru pro­jek­to­wa­nia i imple­men­ta­cji, obser­wu­ję odwrót od metod struk­tu­ral­nych i mono­li­tycz­nych baz rela­cyj­nych. Dzielnie logi­ki biz­ne­so­wej na część w bazie i część w kodzie pro­wa­dzi do dużych trud­no­ści z utrzy­ma­niem jej spój­no­ści w więk­szych pro­jek­tach (a raczej nie da się 100% logi­ki sys­te­mu wtło­czyć w ubo­gi język pro­ce­dur wbudowanych). 

  4. Paweł Ociepka 5 grudnia 2014 at 14:06

    Wymienione wady i zale­ty oby­dwu archi­tek­tur jak naj­bar­dziej są uza­sad­nio­ne. Jednak w nie trak­to­wał­bym archi­tek­tu­ry opar­tej na gru­bym klien­cie jako dino­zau­ra”. Są sytu­acje kie­dy zasto­so­wa­nie tego podej­ścia jest wska­za­ne i ma znacz­ną prze­wa­gę nad sys­te­ma­mi opar­ty­mi o przeglądarkę. 

    Parę lat temu bra­łem udział w pro­jek­cie dla duże­go klien­ta. Kilkanaście tysię­cy jego pra­cow­ni­ków pra­co­wa­ło w tere­nie i nie­ste­ty regu­lar­nie zdą­ża­ły się przy­pad­ki, kie­dy nie mie­li dostę­pu do Internetu. Dlatego stwo­rzy­li­śmy apli­ka­cję gru­be­go klien­ta, któ­ra była wypeł­ni samo­dziel­nym roz­wią­za­niem. Dopiero w momen­cie pod­pię­cia się użyt­kow­ni­ka do sie­ci sys­tem, syn­chro­ni­zo­wał się z cen­tral­ną bazą. Oczywiście przy takiej ska­li, nawet przy zasto­so­wa­niu auto­ma­tycz­nych aktu­ali­za­cji, poja­wi­ły się wymie­nio­ne pro­ble­my (ale w roz­sąd­nej ilo­ści). W tym przy­pad­ku, pro­blem z licen­cja­mi lokal­nych baz danych uda­ło się roz­wią­zać dar­mo­wy­mi wer­sja­mi baz Microsoftu (Express, Compact).

    Inna sytu­acja kie­dy bym brał pod uwa­gę archi­tek­tu­rę z zasto­so­wa­niem gru­be­go klien­ta” – apli­ka­cje wyma­ga­ją­ce pra­cy na cięż­kich obiek­tach. Przykład któ­ry cho­dzi mi po gło­wie to np. obrób­ka gra­fi­ki – cza­sy ocze­ki­wa­nia, aż do klien­ta po prze­li­cze­niach spły­ną obra­zy, zosta­ną prze­sła­ne na ser­wer mógł­by zbić efek­tyw­ność pra­cy pra­wie do zera. 

    Osobiście jestem zwo­len­ni­kiem archi­tek­tu­ry opar­tej o cien­kie­go klien­ta. Niestety spe­cy­fi­ka dane­go sys­te­mu i biz­ne­su nie­ja­ko wymu­sza jed­no lub dru­gie podejście.

    • Jaroslaw Zelinski 5 grudnia 2014 at 17:18

      To praw­da, że są sytu­acje wymy­ka­ją­ce się ogól­nym zale­ce­niom” czy dobrym prak­ty­kom. Generalnie są to te przy­pad­ki gdzie indy­wi­du­alizm pra­cy użyt­kow­ni­ka jest głów­ną cechą dane­go sys­te­mu, a umoż­li­wie­nie tego indy­wi­du­ali­zmu wyma­ga­niem. Klasyką są apli­ka­cje inży­nier­skie i gra­ficz­ne np. mój CASE to cięż­ki klient, ser­wer jedy­nie wer­sjo­nu­je pro­jekt i ana­li­zu­je (na żąda­nie) róż­ni­ce mię­dzy wer­sja­mi, obsłu­gu­je uwa­gi recen­zen­tów. Wiele quasi samo­dziel­nych apli­ka­cji na smart­fo­ny to lokal­ne apli­ka­cje klienc­kie. Przykładów moż­na podać wie­le, jed­nak ja w swo­im arty­ku­le sku­pi­łem się na apli­ka­cjach czy­sto biz­ne­so­wych, gdzie logi­ka biz­ne­so­wa jest jed­na i wspól­na, rola użyt­kow­ni­ka spro­wa­dza się do wpro­wa­dza­nia danych i korzy­sta­nia z danych prze­two­rzo­nych. Tak więc Pana wnio­ski jak naj­bar­dziej są zbież­ne z moimi ;).

  5. Samos 4 sierpnia 2015 at 23:54

    Wskazywanie sys­te­mów obiek­to­wych jako roz­wią­za­nia każ­de­go pro­ble­mu zde­cy­do­wa­nie nie jest popraw­ne. Już dziś wie­my, że podej­ście, któ­re mia­ło dra­stycz­nie obni­żyć kosz­ty pro­duk­cji sys­te­mów infor­ma­tycz­nych odnio­sło prze­ciw­ny sku­tek. Podobnie jest z archi­tek­tu­rą cien­kie­go klien­ta. Po pro­stu cza­sem będzie nie wydaj­na lub zbyt kosz­tow­na (nie­któ­re przy­pad­ki opi­sa­li przed­mów­cy). Oczywiście w przy­pad­ku wie­lu sys­te­mów spraw­dzi się dosko­na­le. Aplikacje z czę­ścią logi­ki prze­cho­wy­wa­ną w pro­ce­du­rach wbu­do­wa­nych baz danych tak­że czę­sto oka­zu­ją się wydaj­niej­sze od wie­lo­war­stwo­wych. A już na pew­no są dużo tań­sze w utrzy­ma­niu i wytwo­rze­niu. Szczególnie w sys­te­mach trans­ak­cyj­nych (zaj­mu­ję się pro­duk­cją spo­re­go sys­te­mu kla­sy ERP i z roz­wią­zań wie­lo­war­stwow­cyh byli­śmy zmu­sze­ni czę­ścio­wo zre­zy­gno­wać z uwa­gi na kosz­ty oraz wydaj­ność systemu).

    • Jaroslaw Zelinski 5 sierpnia 2015 at 09:35

      Prawdą jest, że obiek­to­wość” to nie lekar­stwo na wszel­kie zło” ale… Po pierw­sze podej­ście obiek­to­we nie mia­ło na celu obni­że­nia kosz­tów pro­jek­to­wa­nia i wytwa­rza­nia (bo fak­tycz­nie je pod­no­si) a kosz­tów utrzy­ma­nia i roz­wo­ju (pole­cam [[Open Close pryn­cy­pia]]). Nie myl­my kosz­tów pro­jek­to­wa­nia z kosz­ta­mi utrzy­ma­nia. Projekt i wyko­na­nie rowe­ru spa­wa­ne­go zawsze będzie tań­sze niż zapro­jek­to­wa­nie rowe­ru z masą śru­bek, motyl­ków i stan­dar­do­wych gwin­tów w celu łatwej przy­szłej zmia­ny budo­wy i roz­bu­do­wy rowe­ru. Jednak z jakie­goś powo­du nie pro­du­ku­je się spa­wa­nych rowerów… 

      Nie tyl­ko moim zda­niem powszech­nym błę­dem tech­no­kra­cji” jest uzna­nie, że np. wydaj­ność jest klu­czem: bar­dzo wydaj­ny, ale też bar­dzo kosz­tow­ny w utrzy­ma­niu, sys­tem nie będzie suk­ce­sem biz­ne­so­wym. Zresztą jest masa roz­wią­zań archi­tek­to­nicz­nych roz­wią­zu­ją­cych pro­ble­my wydaj­no­ścio­we (np. CQRS). 

      Wytworzenie apli­ka­cji z logi­ką w pro­ce­du­rach wbu­do­wa­nych jest zapew­ne tań­sze ale z niski­mi kosz­ta­mi jej utrzy­ma­nia bym pole­mi­zo­wał, z regu­ły doda­nie lub zmia­na logi­ki dzia­ła­nia wyma­ga nie raz prze­glą­du (a bywa, że nawet refak­to­rin­gu) cało­ści a sil­ne powią­za­nia wewnętrz­ne (w zasa­dzie żad­nej her­me­ty­za­cji bo całość wią­że jeden rela­cyj­ny, znor­ma­li­zo­wa­ny model danych) unie­moż­li­wia­ją wydzie­le­nie i wymia­nę jakiej­kol­wiek części. 

      Obecnie w zasa­dzie regu­łą na ryn­ku jest zmien­ność tego ryn­ku, fir­my z jed­nych swo­ich funk­cji biz­ne­so­wych rezy­gnu­ją inne adop­tu­ją, sys­te­my zbu­do­wa­ne na zasa­dzie model danych + funk­cje” to mono­lit nie dają­cy się kro­ić na kawał­ki. Z moich doświad­czeń wyni­ka, że spo­ry sys­tem ERP” bar­dzo szyb­ko sta­je się zaka­łą fir­my, bo to stra­te­gia wszyst­ko albo nic”. Regularnie jestem świad­kiem sytu­acji, gdy fir­ma rezy­gnu­je z całe­go ERP bo nie da się zmie­nić tyl­ko jego czę­ści. Niestety to rynek dyk­tu­je wyma­ga­nia a nie tech­no­lo­gia. Owszem 30 lat temu moż­na było zało­żyć, że model dzia­ła­nia fir­my się nie zmie­ni np. 15 lat więc ma sens budo­wa­nie jed­no­li­te­go mode­lu danych dla niej, dzi­siaj nie ma to raczej już sensu. 

      Obiektywność to nie tyl­ko kla­sy i obiek­ty” ale podział duże­go sys­te­mu na nie­za­leż­ne logicz­ne i zin­te­gro­wa­ne kom­po­nen­ty. Nawet jeże­li jeden auto­bus jest tań­szy od 10 samo­cho­dów oso­bo­wych, żad­na roz­sąd­na fir­ma dzi­siaj nie kupi dla dzia­łu han­dlo­we­go auto­bu­su… Ja patrze na to tak: klient raz pła­ci za apli­ka­cję a potem ją utrzy­mu­je np. 10 lat. To archi­tek­tu­ra decy­du­je o kosz­tach utrzy­ma­nia… Co do wydaj­no­ści sys­te­mów z pro­ce­du­ra­mi wbu­do­wa­ny­mi, to bądź­my szcze­rzy: wydaj­ność zabi­ja nor­ma­li­za­cja danych a nie to ile warstw logi­ki ma, bo tych warstw jest naj­wy­żej trzy i popraw­na ich archi­tek­tu­ra raczej spo­wo­du­je wzrost szyb­ko­ści pra­cy niż jej spadek.

      Na koniec war­to nie zapo­mi­nać, że uży­cie pro­ce­dur wbu­do­wa­nych nie­mal­że unie­moż­li­wia wymien­ność ser­we­ra SQL.

  6. Jaroslaw Zelinski 5 sierpnia 2015 at 09:56

    Dodam kil­ka słów wyja­śnie­nia w kwe­stii tak zwa­ne­go gru­be­go klien­ta” bo w powyż­szych komen­ta­rzach prze­mil­cza­no jed­ną waż­ną rzecz doty­czą­ca archi­tek­tu­ry. Gruby klient to archi­tek­tu­ra, w któ­rej na sta­cji użyt­kow­ni­ka jest tyl­ko apli­ka­cja a baza danych sys­te­mu na ser­we­rze, taki klient zdal­nie” korzy­sta z tej bazy danych (wywo­ła­nia SQL po sieci). 

    A to co opi­sał jeden z przedmówców:

    Parę lat temu bra­łem udział w pro­jek­cie dla duże­go klien­ta. Kilkanaście tysię­cy jego pra­cow­ni­ków pra­co­wa­ło w tere­nie i nie­ste­ty regu­lar­nie zdą­ża­ły się przy­pad­ki, kie­dy nie mie­li dostę­pu do Internetu. Dlatego stwo­rzy­li­śmy apli­ka­cję gru­be­go klien­ta, któ­ra była wypeł­ni samo­dziel­nym roz­wią­za­niem. Dopiero w momen­cie pod­pię­cia się użyt­kow­ni­ka do sie­ci sys­tem, syn­chro­ni­zo­wał się z cen­tral­ną bazą.”

    to nie jest klient ser­wer” a auto­no­micz­na apli­ka­cja zin­te­gro­wa­na z dru­gą w cen­tra­li, i to dla odmia­ny jest dość czę­sto spo­ty­ka­ne rozwiązanie.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.