Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: LaLa 15. 04. 2017, 13:15:23
-
Čau,
dělám na projektu, kde v podstatě pravidelně nějaké API volá samo sebe. Abych to zasadil trochu do konkrétníého rámce, tak jedná se o serverové komponenty psané ve Springu a tím api myslím Service layer.
Považuji Service layer za API k aplikaci. A DAO layer za API k datům. A REST layer za API k Service API.
Představte si REST layer - dovedete si představit, že by nějaká REST metoda volala nějakou jinou REST metodu v te same komponentě? Já teda ne a považoval bych to za naprostou prasárnu. Tak proč nějaká Service, volá nejakou jinou Service? Service layer by mělo být to pravé API k aplikaci, které je oproštěno od čehokoliv co se děje na RESTu.
Stejně tak DAO. DAO by měla být nějaká třída práce s Daty a DAO tvoří svůj vlastní layer. Tím je vlastně DAO rovněž API, ale k Datům. Není proto možné, aby jedno DAO volalo nějaké jiné DAO ze stejné vrstvy a co je ještě horší, není možné aby nějaké DAO volalo nějakou Service.
Neříkám to proto, že jsem nějaký hnidopich, ale proto, když vidím ,jaký je na projektech bordel v implementaci bussiness logiky. Business logika takovéto typické serverové komponenty je něco, co se dá nejlépe zapsat pomocí BPMN grafu. Tak prosim vás, pokud nechcete, aby vás nahradili klikači BPMN obrázků, ze kterých se potom bude generovat přehledný kód, do kterého nikdo z vás nebude moct zasahovat, protože by jste ho akorát zprasili, TAK SE NAUČTE PROGRAMOVAT!
-
Čau,
dělám na projektu, kde v podstatě pravidelně nějaké API volá samo sebe. Abych to zasadil trochu do konkrétníého rámce, tak jedná se o serverové komponenty psané ve Springu a tím api myslím Service layer.
Považuji Service layer za API k aplikaci. A DAO layer za API k datům. A REST layer za API k Service API.
Představte si REST layer - dovedete si představit, že by nějaká REST metoda volala nějakou jinou REST metodu v te same komponentě? Já teda ne a považoval bych to za naprostou prasárnu. Tak proč nějaká Service, volá nejakou jinou Service? Service layer by mělo být to pravé API k aplikaci, které je oproštěno od čehokoliv co se děje na RESTu.
Stejně tak DAO. DAO by měla být nějaká třída práce s Daty a DAO tvoří svůj vlastní layer. Tím je vlastně DAO rovněž API, ale k Datům. Není proto možné, aby jedno DAO volalo nějaké jiné DAO ze stejné vrstvy a co je ještě horší, není možné aby nějaké DAO volalo nějakou Service.
Neříkám to proto, že jsem nějaký hnidopich, ale proto, když vidím ,jaký je na projektech bordel v implementaci bussiness logiky. Business logika takovéto typické serverové komponenty je něco, co se dá nejlépe zapsat pomocí BPMN grafu. Tak prosim vás, pokud nechcete, aby vás nahradili klikači BPMN obrázků, ze kterých se potom bude generovat přehledný kód, do kterého nikdo z vás nebude moct zasahovat, protože by jste ho akorát zprasili, TAK SE NAUČTE PROGRAMOVAT!
Ty zas prasíš český pravopis, tak než příště budeš svinit nějaké fórum, nauč se nejdřív správně česky.
-
Když to funguje, tak bych to neřešil.
-
Když to funguje, tak bys to neřešil? >:( >:( >:( A co potom ta údržba, až se do toho budou přidávat další a další věci? Prase jedno!
-
Typická ukázka čuněte, které něco naprasí, pak na to naprasí zas, pak ještě jednou, a když už je to tak zprasené, že se v tom už i blbě dál prasí, tak jde prasit jinam, kde to ještě dost zprasené není!
-
Proč si myslíte, že by všechny služby ve Springu měly tvořit veřejné API? Podle toho vašeho návrhu by všechny služby mohly být jen primitivní, mohly by volat jen datovou vrstvu. K čemu by to bylo dobré?
-
Ked chces spajat servisy tak na to mas fasady
-
Když to funguje, tak bych to neřešil.
To "funguji" i hrebiky nastrkane misto pojistek ;)
-
Když to funguje, tak bych to neřešil.
To "funguji" i hrebiky nastrkane misto pojistek ;)
Nefungují. Při skratování zásuvky se zachovají jinak. Software napsaný různými způsoby se může navenek chovat identicky. Problém bych řešil až po selhání behavoriálního testu.
-
Neříkám to proto, že jsem nějaký hnidopich, ale proto, když vidím ,jaký je na projektech bordel v implementaci bussiness logiky. Business logika takovéto typické serverové komponenty je něco, co se dá nejlépe zapsat pomocí BPMN grafu. Tak prosim vás, pokud nechcete, aby vás nahradili klikači BPMN obrázků, ze kterých se potom bude generovat přehledný kód, do kterého nikdo z vás nebude moct zasahovat, protože by jste ho akorát zprasili, TAK SE NAUČTE PROGRAMOVAT!
Zkusil jsi to už říct autorům toho zpackaného projektu?
-
Čau,
dělám na projektu, kde v podstatě pravidelně nějaké API volá samo sebe. Abych to zasadil trochu do konkrétníého rámce, tak jedná se o serverové komponenty psané ve Springu a tím api myslím Service layer.
Považuji Service layer za API k aplikaci. A DAO layer za API k datům. A REST layer za API k Service API.
Představte si REST layer - dovedete si představit, že by nějaká REST metoda volala nějakou jinou REST metodu v te same komponentě? Já teda ne a považoval bych to za naprostou prasárnu. Tak proč nějaká Service, volá nejakou jinou Service? Service layer by mělo být to pravé API k aplikaci, které je oproštěno od čehokoliv co se děje na RESTu.
Stejně tak DAO. DAO by měla být nějaká třída práce s Daty a DAO tvoří svůj vlastní layer. Tím je vlastně DAO rovněž API, ale k Datům. Není proto možné, aby jedno DAO volalo nějaké jiné DAO ze stejné vrstvy a co je ještě horší, není možné aby nějaké DAO volalo nějakou Service.
Neříkám to proto, že jsem nějaký hnidopich, ale proto, když vidím ,jaký je na projektech bordel v implementaci bussiness logiky. Business logika takovéto typické serverové komponenty je něco, co se dá nejlépe zapsat pomocí BPMN grafu. Tak prosim vás, pokud nechcete, aby vás nahradili klikači BPMN obrázků, ze kterých se potom bude generovat přehledný kód, do kterého nikdo z vás nebude moct zasahovat, protože by jste ho akorát zprasili, TAK SE NAUČTE PROGRAMOVAT!
Niekto si ulahcoval robotu. Taketo prasaciny sa zvyknu vypomstit pri dalsej udrzbe. Radim ukusnut si nohu ako kojot a z projektu utiect. Alebo to prepisat na normalne. Volanie sameho seba cez REST, je plytvanie prostriedkami. A Dao ozaj nema volat service layer, zbytocne sa tam vytvara dalsia zavislost, zhorsuje to znovupouzitelnost dao. A samozrejme nikto normalny nebude predpokladat, ze dao vola service layer, takze to moze sposobit "WTF" chyby.
-
Proč si myslíte, že by všechny služby ve Springu měly tvořit veřejné API? Podle toho vašeho návrhu by všechny služby mohly být jen primitivní, mohly by volat jen datovou vrstvu. K čemu by to bylo dobré?
Protože co jiného by Service tvořila, než nějaké veřejné API? Service by měly být vstupní uzly k aplikaci, neměly by tvořit vnitřní uzly. Vnitřní uzly mezi vrstvou Service a DAO, ať jsou Component. Z aplikace musí být jasně vidět její Business logika a proto to nemůžou být špagety kde Service volají jiné Service. Chci-li se např. podívat, jaká je business logika pro získání informací o zákazníkovi (s nějakou netriviální funkcionalitou typu složitějšího managementu práv nad daty) tak si otevřu danou Service a musím ji jasně vidět jako na stříbrném podnose, na jednom místě, jako kdybych měl před sebou implementované BPMN, nebo jako kdybych používal nějaký BPMN engine a valil BPMN do XMLka (což je otřesné).
-
Volani API z API se pouziva pomerne bezne pro pripady, kdy kdy jedno API volani je specifickym pripadem volani jineho API, pouze nastavuje par default patametru.
Kod je pak lip citelny, hned na urovni API je videt, ze se jedna jenom o specialni pripad obecneho callu.
Napriklad, pokud mam Spring bean s moznosti inicializace pres settery a zaroven pres hashmapu, hashmap inicializace interne zavola settery.
Zalezi na typu pouziti, striktni pravda neexistuje. A zrovna Spring je psany pomerne slusne
-
Protože co jiného by Service tvořila, než nějaké veřejné API?
Servisy tvoří především implementaci. Vedle toho mohou ale nemusí tvořit také veřejné API.
Vnitřní uzly mezi vrstvou Service a DAO, ať jsou Component.
O Component jste předtím vůbec nepsal – myslel jsem, že je zahrnujete mezi service. Každopádně ale Service a Component netvoří dvě různé vrstvy aplikace. Rozdíl mezi Service a Component je ve Springu jenom v tom, že Service se účastní transakce ale Component ne. Klidně si ale můžete nadefinovat vlastní stereotypy a ty Springovské ani nemusíte používat. A i když je použijete, Component mohou být součástí API a Service mohou být jen interní implementace. A dává smysl převolávat i služby, které jsou součástí veřejného API.
Z aplikace musí být jasně vidět její Business logika
Což ale nijak nesouvisí s tím, jak používáte Service nebo Component.
a proto to nemůžou být špagety kde Service volají jiné Service.
Píšete „ a proto“ – já tam ale žádnou souvislost nevidím.
tak si otevřu danou Service a musím ji jasně vidět jako na stříbrném podnose, na jednom místě
Přesně tak. Takže abyste mohl tu logiku jasně vidět na jednom místě (na pár řádcích kódu), musíte kód dekomponovat – z té Service, která tvoří veřejné API, budete postupně volat jednotlivé části implementace. A ty jednotlivé části mohou být další Service – ať už veřejné nebo neveřejné.
Třeba když budete vytvářet objednávku v e-shopu spolu s novou registrací uživatele. Interně zavoláte dvě služby, registraci uživatele a uložení objednávky. Obě jsou součástí veřejného API, protože můžete i zvlášť zaregistrovat uživatele (bez objednávky) a také můžete zvlášť jen uložit objednávku (pro uživatele, který už je registrován). A samotná registrace uživatele ještě bude volat další Service, ověření poštovní adresy. To může být jen interní Service, ale nakonec ji stejně asi budete chtít zveřejnit, abyste mohl validaci adresy dělat už průběžně, jak ji uživatel zadává.
-
Proč si myslíte, že by všechny služby ve Springu měly tvořit veřejné API? Podle toho vašeho návrhu by všechny služby mohly být jen primitivní, mohly by volat jen datovou vrstvu. K čemu by to bylo dobré?
Protože co jiného by Service tvořila, než nějaké veřejné API? Service by měly být vstupní uzly k aplikaci, neměly by tvořit vnitřní uzly. Vnitřní uzly mezi vrstvou Service a DAO, ať jsou Component. Z aplikace musí být jasně vidět její Business logika a proto to nemůžou být špagety kde Service volají jiné Service. Chci-li se např. podívat, jaká je business logika pro získání informací o zákazníkovi (s nějakou netriviální funkcionalitou typu složitějšího managementu práv nad daty) tak si otevřu danou Service a musím ji jasně vidět jako na stříbrném podnose, na jednom místě, jako kdybych měl před sebou implementované BPMN, nebo jako kdybych používal nějaký BPMN engine a valil BPMN do XMLka (což je otřesné).
To není žádná univirzální pravda, jen názor.
-
A čemu že mají sloužit tyto plačky? Tak sis pobrečel. Postěžoval, řekl si nám jakej si mistr světa a že tomu jako rozumíš.
Ale k čemu to bylo dobrý?
-
A čemu že mají sloužit tyto plačky? Tak sis pobrečel. Postěžoval, řekl si nám jakej si mistr světa a že tomu jako rozumíš.
Ale k čemu to bylo dobrý?
Zřejmě chtěl jen potvrdit, že to dělá správně, ale nedočkal se toho.
-
A čemu že mají sloužit tyto plačky? Tak sis pobrečel. Postěžoval, řekl si nám jakej si mistr světa a že tomu jako rozumíš.
Ale k čemu to bylo dobrý?
Zřejmě chtěl jen potvrdit, že to dělá správně, ale nedočkal se toho.
Já tam vidím rozkaz abychom se naučili programovat a ještě na nás křičí. To nevypadá jako nějaká žádost o potvrzení.
-
Já tam vidím rozkaz abychom se naučili programovat a ještě na nás křičí. To nevypadá jako nějaká žádost o potvrzení.
Hmm, tak asi chtěl napsat blogový zápisek a spletl si odkaz.
-
Jak už bylo řečeno, položil bych si otázku, co by vlastně ty services dělaly, pokud by nevolaly jiné services?
-
To není žádná univirzální pravda, jen názor.
To je jenom pulka pravdy. Druha pulka pravdy je to, ze ne kazdy nazor je tak opodstatneny jako jiny.
Stejne jako neexistuje "univerzalni umeni", tak to stale jeste neznamena, ze Mona Lisa nebo Beethovenova pata nejsou lepsi, nez cokoli namaluju nebo vytukam na piano.
-
Když to funguje, tak bych to neřešil.
To "funguji" i hrebiky nastrkane misto pojistek ;)
Nefungují. Při skratování zásuvky se zachovají jinak. Software napsaný různými způsoby se může navenek chovat identicky. Problém bych řešil až po selhání behavoriálního testu.
Tohle není dobrý přístup, protože ignoruje náklady na údržbu a rozvoj softwaru. Když budeš mít za úkol opravit chybu nebo přidat nějakou novou funkci, bude ti to při zpraseném návrhu trvat mnohem déle (a dost možná při tom zaneseš do kódu nové chyby). Přesto ti všechny testy budou hezky procházet a i uživatelé můžou být s funkcí programu spokojení (ovšem už nebudou spokojeni s tím, kolik je stojí doprogramování něčeho nového nebo jak dlouho trvá oprava chyby).
-
Když to funguje, tak bych to neřešil.
To "funguji" i hrebiky nastrkane misto pojistek ;)
Nefungují. Při skratování zásuvky se zachovají jinak. Software napsaný různými způsoby se může navenek chovat identicky. Problém bych řešil až po selhání behavoriálního testu.
Tohle není dobrý přístup, protože ignoruje náklady na údržbu a rozvoj softwaru. Když budeš mít za úkol opravit chybu nebo přidat nějakou novou funkci, bude ti to při zpraseném návrhu trvat mnohem déle (a dost možná při tom zaneseš do kódu nové chyby). Přesto ti všechny testy budou hezky procházet a i uživatelé můžou být s funkcí programu spokojení (ovšem už nebudou spokojeni s tím, kolik je stojí doprogramování něčeho nového nebo jak dlouho trvá oprava chyby).
Aneb jak se rika hned na pvnich hodinach softwareoveho inzenyrstvi -- software ma vnejsi a vnitrni kvality a pokud ty vnitrni kvality absentuji, tak se daleko hur dosahuje tech vnejsich ;)