Wzorzec MVC – dyskusja c.d.

Wprowadzenie

Wzorzec ten budzi wie­le kon­tro­wer­sji co do tego czym są te trzy kom­po­nen­ty. Popatrzmy do anglo­ję­zycz­nej WIKI: 

Model – Centralny kom­po­nent wzor­ca. Jest to dyna­micz­na struk­tu­ra danych apli­ka­cji, nie­za­leż­na od inter­fej­su użyt­kow­ni­ka. Bezpośrednio zarzą­dza dany­mi, logi­ką i regu­ła­mi apli­ka­cji. W Smalltalk-80, model jest cał­ko­wi­cie pozo­sta­wio­ny pro­gra­mi­ście. W WebObjects, Rails i Django, model zazwy­czaj repre­zen­tu­je tabe­lę w bazie danych aplikacji.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Jest to domi­nu­ją­ca defi­ni­cja w lite­ra­tu­rze, zaś spo­ry o to czym jest Model w archi­tek­tu­rze MVC jak widać mają jed­no głów­ne źró­dło: jakie­go fra­me­wor­ka uży­wa oso­ba wcho­dzą­ca w takie spo­ry. WIKI Cytuje to opra­co­wa­nie: https://​medium​.com/​f​r​e​e​-​c​o​d​e​-​c​a​m​p​/​s​i​m​p​l​i​f​i​e​d​-​e​x​p​l​a​n​a​t​i​o​n​-​t​o​-​m​v​c​-​5​d​3​0​7​7​9​6​d​f30, zawie­ra­ją­ce mię­dzy inny­mi tę ilu­stra­cje wyja­śnia­ją­cą o co chodzi:

„Model to dyna­micz­na struk­tu­ra danych apli­ka­cji, nie­za­leż­na od inter­fej­su użyt­kow­ni­ka. Bezpośrednio zarzą­dza dany­mi, logi­ką i regu­ła­mi apli­ka­cji.”

Z czym sie spotykamy

Popatrzmy na popu­lar­ne ​„dewe­lo­per­skie” artykuły:

https://​www​.fre​eco​de​camp​.org/​n​e​w​s​/​t​h​e​-​m​o​d​e​l​-​v​i​e​w​-​c​o​n​t​r​o​l​l​e​r​-​p​a​t​t​e​r​n​-​m​v​c​-​a​r​c​h​i​t​e​c​t​u​r​e​-​a​n​d​-​f​r​a​m​e​w​o​r​k​s​-​e​x​p​l​a​i​n​ed/

To kla­sycz­na wer­sja bazu­ją­ca na popu­lar­nym podej­ściu, mówią­cym, że Model to dane a Controller to logi­ka biz­ne­so­wa a View to aktu­al­ny stan tej bazy danych. Autor wprost pisze: sets data via setters/getters (tak przy oka­zji set/get w kla­sach to jed­nak z naj­gor­szych prak­tyk pro­jek­to­wa­nia obiek­to­we­go: pobra­nie dowol­ne­go doku­men­ty wyma­ga nie raz wywo­ła­nia kil­ku­dzie­się­ciu ope­ra­cji, łamie­my her­me­ty­za­cję, itp.). 

Powyższe to pro­ste podej­ście zna­ne ze sta­rych struk­tu­ral­nych narzę­dzi dewe­lo­per­skich ope­ru­ją­cych trze­ma war­stwa­mi (np. Oracle Forms, JavaEE czy ASP​.NET):

https://​www​.geeks​for​ge​eks​.org/​w​h​a​t​-​i​s​-​n​e​t​-​3​-​t​i​e​r​-​a​r​c​h​i​t​e​c​t​u​re/

I war­stwy te utoż­sa­mia­ne są odpo­wied­nio z View (Presentation Tier), Controller (Business Tier) oraz Model (Data Tier). Baza SQL (rela­cyj­na) to imple­men­ta­cja utrwa­la­nia. Podejście to nadal jest obec­ne w wie­lu fra­me­wor­kach mają­cych rodo­wo­dy w latach 80/90 ubie­głe­go wieku. 

Kolejnym błę­dem jest utoż­sa­mia­nie MVC z wzor­cem BCE (Boundary, Control, Entity). Wzorzec ten ma swój rodo­wód opar­ty na poli­ty­ce pro­jek­to­wa­nia zorien­to­wa­nej na odpo­wie­dzial­ność klas [Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88.]:

https://​tschut​schu​.de/​r​e​s​o​u​r​c​e​s​/​t​s​c​h​u​t​s​c​h​u​/​d​o​c​s​/​S​S​2​0​1​4​/​S​S​2​0​1​4​_​1​5​_​G​u​r​p​r​e​e​t​_​D​h​a​m​i​_​E​C​B​-​P​P​_​v​3​.​pdf

Istota tego wzor­ca to przy­ję­cie pro­stej zasa­dy mówią­cej, że kla­sa ma jed­na wąską odpo­wie­dzial­ność i są to trzy bazo­we, alter­na­tyw­ne spe­cja­li­za­cje: inter­fa­ce (Boundary) zamy­ka­ją­ca wej­ście do środ­ka kom­po­nen­tu, logi­ka (Control) reali­zu­ją­ca prze­twa­rza­nie (prze­cho­wu­je algo­ryt­my i meto­dy) oraz utrwa­la­nie danych repre­zen­tu­ją­cych obiek­ty biz­ne­so­we (Entity). Czyli np. wali­da­tor for­mu­la­rza będzie kla­są typu Control, a sam for­mu­larz (cały) będzie prze­cho­wy­wa­ny w kla­sie Entity. 

Popatrzmy teraz na to:

https://​www​.java​gu​ico​de​xam​ple​.com/​i​n​f​o​r​m​a​t​i​o​n​s​y​s​t​e​m​d​e​v​e​l​o​p​m​e​n​t​1​.​h​tml

Autor uży­wa tych sym­bo­li by poka­zać trzy war­stwy: GUI, logi­ka, baza danych. Jeżeli jakie­kol­wiek apli­ka­cje mają taką archi­tek­tu­rę, są potęż­ny­mi monolitami. 

Architektura heksagonalna

W 2005 roku Cocburn opi­sał podej­ście do archi­tek­tu­ry, któ­re nazwał: Architektura hek­sa­go­nal­na [Cockburn, A. (2005, January 4). Hexagonal archi­tec­tu­re. Alistair Cockburn. https://​ali​sta​ir​.cock​burn​.us/​h​e​x​a​g​o​n​a​l​-​a​r​c​h​i​t​e​c​t​u​re/]. Idea tego pomy­słu pole­ga na podzia­le kodu apli­ka­cji na dwa obsza­ry: Aplikacja, czy­li cały i tyl­ko kod reali­zu­ją­cy funk­cjo­nal­ność opro­gra­mo­wa­nia (w tym to jak i jaki­mi dany­mi zarzą­dza) oraz resz­ta, czy­li śro­do­wi­sko w jakim ten kod sie wyko­nu­je (zwa­ne kie­dyś Run Time). To śro­do­wi­sko jest widzia­ne jako adap­te­ry (API) udo­stęp­nia­ją­ce poza­funk­cjo­nal­ne ele­men­ty takie jak nośni­ki danych, usłu­gi wysy­ła­nia odbie­ra­nia komu­ni­ka­tów (SMS, ema­il, itp.), dostęp do sie­ci Internet, usłu­gi VPN, Interfejs użyt­kow­ni­ka, dru­kar­ki itp. Schematycznie wyglą­da to tak:

Cockburn, A. (2005, January 4). Hexagonal archi­tec­tu­re. Alistair Cockburn. https://​ali​sta​ir​.cock​burn​.us/​h​e​x​a​g​o​n​a​l​-​a​r​c​h​i​t​e​c​t​u​re/

Bardziej pre­cy­zyj­nie zobra­zo­wa­no to na tym schemacie:

źr.: https://​her​ber​to​gra​ca​.com/​2​0​1​7​/​1​1​/​1​6​/​e​x​p​l​i​c​i​t​-​a​r​c​h​i​t​e​c​t​u​r​e​-​0​1​-​d​d​d​-​h​e​x​a​g​o​n​a​l​-​o​n​i​o​n​-​c​l​e​a​n​-​c​q​r​s​-​h​o​w​-​i​-​p​u​t​-​i​t​-​a​l​l​-​t​o​g​e​t​h​er/

Co mamy na powyż­szym dia­gra­mie? Separacja trzech obsza­rów: kod reali­zu­ją­cy dia­log z czło­wie­kiem po lewej (User Interface), kod funk­cjo­nal­ność apli­ka­cji w środ­ku obra­mo­wa­ny czer­wo­na linią (Application Core) oraz kod reali­zu­ją­cy wszel­kie pozo­sta­łe poza­funk­cjo­nal­ne usłu­gi (Infrastructure). W tej kolej­no­ści były by to: V‑M-C. Z uwa­gi (chy­ba na wygo­dę wymo­wy albo waż­ność tych ele­men­tów) pisze­my MVC. Niektórzy auto­rzy w miej­sce lite­ry M wsta­wia­ją sło­wo Model (Domain Model). 

Konsekwencje

W kon­se­kwen­cji wyła­nia się podział dzia­ła­ją­cej apli­ka­cji na dwie zasad­ni­cze czę­ści: kom­po­nent reali­zu­ją­cy wyma­ga­ną funk­cjo­nal­ność apli­ka­cji oraz śro­do­wi­sko w jakim ten kom­po­nent funk­cjo­nu­je czy­li biblio­te­ki, ste­row­ni­ki itp. ogól­nie zwa­ne adapterami: 

Aplikacja i jej śro­do­wi­sko wykonawcze.

Nie przy­pad­kiem jed­ną z pierw­szych prac dewe­lo­pe­ra jest zesta­wie­nie ​„sto­su tech­no­lo­gicz­ne­go” czy­li śro­do­wi­ska w jakim apli­ka­cja (jak zosta­nie napi­sa­na) będzie się wykonywała. 

Z innej per­spek­ty­wy moż­na to poka­zać tak: 

Komponenty View, Controller, Model i ich stan­dar­do­we zależności.

A teraz wyobraź­my sobie, że nasza apli­ka­cja obej­mu­je obszar ozna­czo­ny tur­ku­so­wym kolorem: 

To jaki to jest wzo­rzec archi­tek­to­nicz­ny? Tak, nadal są w uży­ciu takie fra­me­wor­ki zwa­ne ​„lega­cy archi­tec­tu­re”. Nazywane cza­sa­mi sar­ka­stycz­nie ​„roz­sma­ro­wa­niem logi­ki po całości”. 

Podsumowanie

Tak więc archi­tek­tu­ra MVC to archi­tek­tu­ra cało­ści dzia­ła­ją­cej apli­ka­cji gdzie Model to (makro)komponent reali­zu­ją­cy jej funk­cjo­nal­no­ści. Wzorzec BCE to poli­ty­ka mode­lo­wa­nia archi­tek­tu­ry kom­po­nen­tu na niskim pozio­mie (poje­dyn­cze klasy/obiekty).

Ścisłe sepa­ro­wa­nie kon­tek­stów i odpo­wie­dzial­no­ści kom­po­nen­tów to klu­czo­wa zasa­da metod obiek­to­wych: her­me­ty­za­cja. Jakiekolwiek mie­sza­nie odręb­nych obsza­rów logi­ki i wyma­gań szyb­ko dopro­wa­dza dowol­ny pro­jekt do posta­ci monolitu.

Na koniec zacy­tu­ję cie­ka­wy artykuł:

The pro­ducts we build sho­uld never aim to reflect reali­ty lite­ral­ly. The (phy­si­cal) reali­ty is unbo­und and infi­ni­te­ly com­plex – most of its deta­ils are just noise & distrac­tions. We need its sim­pli­fied, fil­te­red ver­sion – the­se parts (/aspects) of the reali­ty that are rele­vant in the cur­rent con­text. DDD calls it a ​„model”.

The failed pro­mi­se of Domain-Driven Design

Warto tak­że spoj­rzeć na opis w ang. WIKI:

Opisany jako:

Model-widok-kon­tro­ler (ang. MVC) […] Elementy te to wewnętrz­ne repre­zen­ta­cje infor­ma­cji (model), inter­fejs (widok), któ­ry pre­zen­tu­je infor­ma­cje użyt­kow­ni­ko­wi i przyj­mu­je je od nie­go, oraz opro­gra­mo­wa­nie kon­tro­le­ra łączą­ce te dwa elementy.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Warto tu przy­po­mnieć, że ​„wewnętrz­ne repre­zen­ta­cje infor­ma­cji (model)” to nic inne­go jak dane i logi­ka ich prze­twa­rza­nia a nie ​„baza danych”. To dla­te­go nie­któ­rzy auto­rzy przy­wo­łu­ją tu archi­tek­tu­rę hek­sa­go­nal­ną, któ­ra zakła­da wydzie­le­nie reali­za­cji wyma­gań funk­cjo­nal­nych jako osob­ne­go kom­po­nen­tu: to jest wła­śnie kom­po­nent Model. 

Przykład

Etapy wytwa­rza­nia oprogramowania:

Umowa na wytwo­rze­nia opro­gra­mo­wa­nia to model przy­pad­ków użycia:

Kontekst i zakres pro­jek­tu: sepa­ra­cja spe­cy­fi­ko­wa­nia usług.

Prostokąt ​„Aplikacja dla Biblioteki” to cała dzia­ła­ją­ca apli­ka­cja. W pro­jek­cie jest to Model, bo pierw­sze klu­czo­we zało­że­nie to: nie będzie­my pisa­li kodu obsłu­gu­ją­ce­go sprzęt i stan­dar­do­we ele­men­ty wej­ścia i wyj­ścia, bo to daje nam śro­do­wi­sko (sys­tem ope­ra­cyj­ny i fra­me­work, itp.). Dlatego sku­pia­my się na zapro­jek­to­wa­nia Mechanizmu dzia­ła apli­ka­cji (zwa­na czę­ścią dziedzinową). 

Najpierw pro­jek­tu­je­my archi­tek­tu­rę HLD (High Level Design):

Architektura HLD: sepa­ra­cja imple­men­ta­cji usług.

Na tym mode­lu mamy podział na kom­po­nen­ty, wewnętrz­ną inte­gra­cję i inte­gra­cją z inny­mi apli­ka­cja­mi. Na tym pozio­mie głów­nym wzor­cem są mikro­ser­wi­sy i wzo­rzec saga. Na tym eta­pie podej­mu­je­my decy­zje, któ­re kom­po­nen­ty kupu­je­my na ryn­ku, a któ­re two­rzy­my sami. Na tym pozio­mie testu­je­my tak­że sce­na­riu­szy przy­pad­ków uży­cia. Np. wypożyczenie:

Poglądowy sce­na­riusz HLD dla usłu­gi wypo­ży­cze­nia: sepa­ra­cja odpowiedzialności.

Kolejny krok to kolej­ne pro­jek­to­wa­nie każ­de­go kom­po­nen­tu, któ­ry two­rzy­my sami. Przykład jed­ne­go z nich:

Architektura LLD: sepa­ra­cja funkcji.

Na tym pozio­mie są bazo­wym wzor­cem jest BCE oraz pod­sta­wo­we wzor­ce: łań­cuch odpo­wie­dzial­no­ści, repo­zy­to­rium, envelope. 

Całość na każ­dym eta­pie testu­je­my (komu­ni­ka­cja, sce­na­riu­sze) dia­gra­ma­mi sekwen­cji. A gdzie tak popu­lar­ne ​„dia­gra­my klas”? Dane i ich logi­kę mode­lu­ją formularze:

Model struk­tu­ry doku­men­tów, for­mu­la­rzy, komu­ni­ka­tów: sepa­ra­cja kontekstów.

Jeżeli wyma­ga­ne jest opi­sa­ne meto­dy (algo­ryt­mu) reali­za­cji ope­ra­cji obiek­tu, two­rzy­my algorytm:

Algorytm, pro­ce­du­ra: sepa­ra­cja metod. 

Wszystko to powy­żej reali­zu­je kom­po­nent Model. Reszta to wyma­ga­nia poza­funk­cjo­nal­ne i infra­struk­tu­ra (kom­po­nen­ty View i Controller). Aż tyle i tyl­ko tyle. 

Powyższa doku­men­ta­cja opi­su­je to jak to wszyst­ko dzia­ła (cała logi­ka biz­ne­so­wa w jed­nym miej­scu). Po wydru­ku będzie mia­ła nawet tysiąc razy mniej­szą obję­tość niż peł­ny wydruk kodu źró­dło­we­go jaki ona opi­su­je. Jest tak­że nie­za­leż­na od metod imple­men­ta­cji. Jak sądzisz czy­tel­ni­ku, co będzie czy­ta­ne przez nowych człon­ków zespo­łu, urzęd­ni­ka Urzędu Patentowego czy inwe­sto­ra przej­mu­ją­ce­go apli­ka­cję? Ja sądzisz, lepiej użyć nota­cji UML, któ­ra de fac­to zna cały świat czy jakiejś niszo­wej meto­dy zna­nej nie­mal­że tyl­ko auto­ro­wi tych dokumentów?

A gdzie są mitycz­ne dia­gra­my klas peł­ne drzew dzie­dzi­cze­nia i kom­po­zy­cji? Nie ma bo są bez­war­to­ścio­we, a jeże­li fak­tycz­nie ktoś tak kodu­je, to są to mega kosz­tow­ne monolity… 

Jeżeli Twój sys­tem lub jego pro­jekt jest podob­ny do poniż­sze­go sche­ma­tu, to zna­czy, że Twój pro­jekt jest jed­nak porażką…

Jak tego nie robić…

Słowa kluczowe: , , ,

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 16 komentarzy

  1. Krzysztof 26 stycznia 2024 Odpowiedz

    Super mate­riał.

  2. Sławek Sobótka 26 stycznia 2024 Odpowiedz

    Z MVC jest total­ny bur­del. Nawet cytat z wiki jest nie­lo­gicz­ny, bo z jed­nej stro­ny model ma logi­kę a z dru­giej model to tabel­ki (ew. encje je odzwier­cie­dla­ją­ce w kla­sach). Czasem MVC jest archi­tek­tu­rą apli­ka­cyj­ną całej apli­ka­cji, cza­sem tyl­ko war­stwy pre­zen­ta­cyj­nej. Czym to skut­ku­je… W pierw­szym podej­ściu kon­tro­ler zaj­mu­je się wszyst­kim: wali­da­cją, kon­tro­lą prze­pły­wu pomię­dzy wido­ka­mi i logi­ką biz­ne­so­wą (bo encje ane­micz­ne, bo tuto­rial do fra­me­wor­ka musi być dopa­so­wa­ny dla ludzi z dwu­cy­fro­wym iq). W dru­gim podej­ściu model jest mode­lem pre­zen­ta­cyj­nym, kon­tro­ler zaj­mu­je się kon­tro­lą prze­pły­wu gui, a pod war­stwą ui mamy osob­ne war­stwy czy pier­ście­nie hexa­go­nu zależ­nie od pozio­mu zło­żo­no­ści logi­ki. Ale kie­dy zaj­rzeć do mate­ria­łów z lat 80 to model nie musiał być ane­micz­ny. Dalej mamy waria­cje na temat MVC: MVVM, MVP, PAC itd, któ­re pró­bu­ją roz­wią­zać pro­blem umiej­sco­wie­nia i rodza­jów logi­ki. A od tego mim zda­niem trze­ba zacząć: jakie są rodza­je logi­ki? Kolejno od góry, czy­li od inten­cji use­ra: wali­da­cja syn­tak­tycz­na, wali­da­cja biz­ne­so­wa, logi­ka pro­ce­su i jego sta­nu, logi­ka inte­gra­cjim logi­ka flow ui, logi­ka biz­ne­so­wa: spój­ność zmia­ny sta­nu biz­ne­su (nie pro­ce­su), obliczenia/transformacje, spój­ność zmia­ny danych. Więc poja­wia się pyta­nie: w któ­ry rodzaj logi­ki anga­żu­je się ana­li­tyk? Na koniec pyta­nie o przy­kład z biblio­te­ką, bo wyglą­da on na zorien­to­wa­ny na obieg doku­men­tów ale nie widać jakie są regu­ły dzie­dzi­ny, któ­re decy­du­ją jak te doku­men­ty obsłu­gi­wać. Coś jak wnio­ski w urzę­dzie: wnio­ski są api peten­ta aby nie znał dome­ny urzęd­ni­ka. Ale wra­ca­jąc do pyta­nia: kie­dy wypo­ży­czam książ­kę, to zmie­nia się stan zaso­bów biblio­te­ki i zmie­nia się stan mojej kar­ty biblio­tecz­nej. Gdzie jest logi­ka koor­dy­nu­ją­ce te dwie zmiany?

    1. Jarosław Żeliński 26 stycznia 2024

      Oczywiście, że z MVC jest ​„bur­del” każ­dy dostaw­ca fra­me­wor­ka ​„rozu­mie go po swo­je­mu”. Jest dokład­nie tak jak napi­sa­łeś, dla­te­go wie­lu ludzi ​„się­ga do źró­deł” abstrakcji. 

      Na to dodat­ko­wo nakła­da się bar­dzo waż­ny pro­blem jakim jest prze­no­szal­ność apli­ka­cji i doku­men­to­wa­nie (w tym ochro­na war­to­ści inte­lek­tu­al­nych). I tu poja­wia sie ​„roz­wią­za­nie”:

      - to co kupu­je­my jako narzę­dzie i śro­do­wi­sko to ​„tool”, to dosta­je­my i uży­wa­my a nie tworzymy, 

      - jeże­li odse­pa­ru­je­my to co two­rzy­my od tego co dosta­je­my (śro­do­wi­sko), to wie­my co ewen­tu­al­nie będzie­my prze­no­sić na inną plat­for­mę, do inne­go języ­ka pro­gra­mo­wa­nia (z tego co mówił A. Cockburn na jed­nym z nie­daw­nych webi­na­riów, to wła­śnie mu przy­świe­ca­ło gdy pisał dok­to­rat o archi­tek­tu­rze heksagonalnej)

      - w kon­se­kwen­cji doku­men­ta­cja całe­go sys­te­mu to TYLKO opis logi­ki ale całej czy­li wraz z dany­mi (Model) i dołą­czo­na doku­men­ta­cja uży­te­go środowiska. 

      Dlatego ​„z góry patrząc”:
      – śro­do­wi­sko wyko­naw­cze to Controller (sesje, wszel­kie API do sprzę­tu, poda­wa­nie aktu­al­ne­go cza­su czy ID zalo­go­wa­ne­go, itp)
      – inte­pre­to­wa­nie komu­ni­ka­tów z Modelu dla ludzi (wymia­na tre­ści) to View (i tu nie­koń­czą­ce się dys­ku­sje o pako­wa­niu logi­ki biz­ne­so­wej do widoków)
      – ser­ce apli­ka­cji (jej cała funk­cjo­nal­ność) to Model, któ­ry moż­na (powin­no sie dać) w dowol­nym momen­cie prze­nieść w inne środowisko.

    2. Jarosław Żeliński 26 stycznia 2024

      „jakie są rodza­je logiki?”

      1. dane są z ​„ludz­kiej” per­spek­ty­wy gru­po­wa­ne w dokumenty/komunikaty (for­mu­la­rze)
      2. wali­du­je­my pola tych formularzy
      3. jeże­li są związ­ki mię­dzy pola­mi (jed­ne­go lub wie­lu for­mu­la­rzy) są to regu­ły, a bywa, że zło­żo­ne algorytmy

      i to jest 100% logi­ki reali­zo­wa­nej przez Model. Reszta to poza­funk­cjo­nal­ne pro­ble­my roz­wią­zy­wa­ne po stro­nie infrastruktury.

  3. Sławek Sobótka 26 stycznia 2024 Odpowiedz

    Co w przy­pad­ku, kie­dy mamy sys­tem z ​„głę­bo­ką” logi­ką, czy­li dane z for­mu­la­rzy­ków, to tyl­ko prze­ka­za­nie małej ilo­ści para­me­trów wej­ścio­wych. Pod spodem jest kil­ka razy wię­cej danych pobie­ra­nych z bazy i innych źró­deł, masa logi­ki i odwo­łań do innych ser­wi­sów (dla utrud­nie­nia zdal­nych, któ­re mają swo­le SLA, więc logi­ka kom­pen­sa­cji docho­dzi, biz­ne­so­wej kom­pen­sa­cji). Słynne ​„kup teraz” na alle­gro. Czym wte­dy będzie model wyrażony?

    1. Jarosław Żeliński 26 stycznia 2024

      Głęboka logi­ka to mity albo dra­mat. Dramat jest gdy wpa­ku­je­my logi­kę do infra­struk­tu­ry, wte­dy jest masakra.
      1. formularze/komunikaty to i tak jedy­na for­ma komunikacji
      2. jed­na SQL baza danych ​„pod spodem” to wła­śnie masa­kra logi­ki umiesz­czo­nej w infrastrukturze
      dalej
      3. dowol­ny sys­tem to skoń­czo­na licz­ba ​„agre­ga­tów danych” i logi­ki komu­ni­ka­cji mię­dzy nimi
      4. wymia­na danych mię­dzy agre­ga­ta­mi to sekwen­cje, z per­spek­ty­wy sys­te­mu każ­de API (SLA nie ma tu nic do rze­czy) do zewnętrz­ne­go sys­te­mu to kolej­ny agregat
      5. słyn­ne ​„kup-teraz” to pro­sta reali­za­cja natych­mia­sto­we­go zamknię­cia aukcji (sta­tus agre­ga­tu) i wysta­wie­nia fak­tu­ry na bazie danych z tego agre­ga­tu (czy­li kolej­ny agregat)

      Model to całość tego co opi­sa­łem powy­żej, resz­ta to infra­struk­tu­ra, któ­ra nie powin­na zawie­rać jakiej­kol­wiek logi­ki biznesowej.

  4. Sławek Sobótka 26 stycznia 2024 Odpowiedz

    Ok, to w przy­kła­dzie biblio­te­ki, gdzie mamy zaso­by biblio­te­ki i kar­ty. Co będzie agre­ga­ta­mi, jak będą się komu­ni­ko­wać i gdzie będzie logi­ka zapew­nie­nia, że zmie­nią się one spój­ne a wra­zie gdy­by nie (sys­tem roz­pro­szo­ny) to coś będzie­my kompensować?

    1. Jarosław Żeliński 26 stycznia 2024

      1. agre­ga­tem są: kar­ta wypo­ży­cze­nia, kar­ta zaso­bu, kar­ta czytelnika
      2. agre­ga­ty z zasa­dy sie mię­dzy soba nie komu­ni­ku­ją (to antyw­zo­rzec), to koor­dy­na­tor (Saga) czy­ta i zapi­su­je komu­ni­ka­ty z dzie­dzi­no­wych kom­po­nen­tów zawie­ra­ją­cych agregaty
      3. nadal nie wiem co to takie­go ta mitycz­na kompensacja
      4. to, że sys­tem jest roz­pro­szo­ny nie ma tu żad­ne­go znaczenia.

      powyż­sze masz poka­za­ne w pod­su­mo­wa­niu artykułu.

  5. Sławek Sobótka 26 stycznia 2024 Odpowiedz

    Luz, ja wiem jak to zro­bić na kil­ka spo­so­bów:) Naprowadzam tyl­ko na to, że trze­ba dodać nowe kloc­ki do tego mvc, bo nie­wie­le z same­go mvc da się ule­pić. Rozproszenie ma zna­cze­nie z powo­du tech­nicz­ne­go: nie­moż­li­wość zało­że­nie trans­ak­cji na kil­ka agre­ga­tów, co nie­ste­ty wpły­nie na biz­nes, bo fizy­ka, i trze­ba to uwzględ­nić w pro­ce­sie biz­ne­so­wym, np. kom­pen­su­jąc, czy­li wyco­fu­jąc już poczy­nio­ne kroki.

    1. Jarosław Żeliński 26 stycznia 2024

      ” trze­ba dodać nowe kloc­ki do tego mvc”
      owszem, bo MVC to jedy­nie podział na naj­wyż­szym poziomie

      „nie­moż­li­wość zało­że­nie trans­ak­cji na kil­ka agregatów”
      nie ma takiej potrze­by gdy nie ma współ­dzie­lo­nej bazy pod spodem 

      „kom­pen­sa­cja”
      jak wyżej

      Bo gene­ral­nie to co widzę w wie­lu pro­jek­tach, to naj­pierw z nie­wia­do­me­go powo­du powsta­je jed­na rela­cyj­na baza danych, a potem cały zespół dziel­nie wal­czy z jej wadami…

  6. Sławek Sobótka 26 stycznia 2024 Odpowiedz

    Nie to, że nie ma potrze­by przy kil­ku bazach danych. Nie ma takiej fizycz­nej moż­li­wo­ści (zakła­dam, że odrzu­ca­my trans­ak­cje roz­pro­szo­ne). No i tu zaczy­na­ją się scho­dy. Co jeże­li zapis do jed­nej bazy się powie­dzie a do innej już nie?

    1. Jarosław Żeliński 27 stycznia 2024

      „Nie ma takiej fizycz­nej moż­li­wo­ści (zakła­dam, że odrzu­ca­my trans­ak­cje roz­pro­szo­ne). No i tu zaczy­na­ją się scho­dy. Co jeże­li zapis do jed­nej bazy się powie­dzie a do innej już nie?”

      Jeżeli z góry zakła­dasz model rela­cyj­ny, set­ki połą­czo­nych tabel i kilo­me­tro­we Selecty to tak. Ale są inne moż­li­wo­ści, któ­re tego nie wyma­ga­ją. Bo Ty z góry zakła­dasz archi­tek­tu­ra poka­za­ną w powyż­szym tek­ście jak ​„roz­sam­ro­wa­ną”.

    1. Jarosław Żeliński 27 stycznia 2024

      Dokumentowy to jest sys­tem prze­cho­wy­wa­nia danych a nie ​„bazy jako takie”. W doku­men­to­wym sys­te­mie zacho­wa­nie nawet bar­dzo skom­pli­ko­wa­nej fak­tu­ry nie jest żad­nym ​„selek­tem z set­ka tablic” tyl­ko pro­stym zacho­wa­niem jed­ne­go strin­gu w jed­nym kro­ku do jed­ne­go atry­bu­tu. Dlatego tu nie wystę­pu­ją żad­ne pro­ble­mu o jakich piszesz. Zapis tak­że jest jed­nym kro­kiem, więc nie ma potrze­by żad­nej kom­pen­sa­cji. Jeżeli tych fak­tur jest sto milio­nów, to i tak każ­da na swo­je ID i możesz je bez pro­ble­mu zapi­sać na dowol­nej licz­bie osob­nych ser­we­rów i nie ma z tym, żad­ne­go problemu. 

      Te strin­gi nie nie nio­są też żad­nej logi­ki, więc nie ma tu żad­nej kło­po­tli­wej ​„płyt­kiej i głę­bo­kiej logiki”.

Dodaj komentarz

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