Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Arty 16. 10. 2018, 10:25:38
-
Ahoj,
pro své účely jsem si dělal aplikaci s použitím hibernate, spring mvc a front jsp.
Jednalo se o projekt, který by se dal použít pro nemocnici.
Zajímaji mě příklady z praxe, jelikož jsem student. Co přesně se dělá v backendu s použitím springu? Já ve svém projektu skončil s natáhnutí dat z db, sql, nějaká validace, kontrola dat, zabezpečení,, uložení dat do db a poslání dat na front end.
Je mi jasné, že třeba u bank je mnohem více práce na backendu.
Čili bych Vás chtěl poprosit, zda byste mi udali nějaké příklady z praxe, nějaké návrhy, co bych si mohl naprogramovat a procvičit se a bude to na tom backendu složitější, kde se dají použít nějaké pokročilé algoritmy atp.
Mockrát díky
-
typicky se oddeluje frontend od backendu takovym zpusobem, ze FE nema sitovou konektivitu (fw deny) k BE a BE ma sitovou konektivitu k FE. Jak vyresis funkcionalitu webu ktery potrebuje nejaky username/password ktery je v BE databazi ke ktere nemas pristup z FE? To same ostatni funkcionalita na webu - kliknes generovat neco a ten job musi vzit BE od FE, zpracovat ho a predat zase FE ktery ho reprezentuje uzivateli... S timhle si muzes hrat pokud chces nekam do banky, ale v praxi budes bastlit nejakou korporatni s*acku.
-
Backend často ukládá data do několika databází (evidenci do SQL databáze, podporu pro vyhledávání do fulltextové databáze nebo nějaké obecné NoSQL databáze, dokumenty do nějakého DMS) a komunikuje s dalšími systémy (REST, SOAP/XML, proprietární protokoly). Může notifikovat jiné systémy nebo uživatele (message queue, e-mail), může provádět nějaké akce podle kalendáře (např. uzávěrky účetnictví na konci měsíce, kvartálu, roku). Může generovat reporty nebo grafy (sice to obsahově patří do frontendu, ale třeba PDF, XLS nebo grafy je lepší generovat na backendu a na frontend už je poslat hotové).
Pokročilé algoritmy budou spíš v konkrétní doméně, pro nemocnici třeba plánování služeb nebo hlídání expirace léků a objednávání. Backend obecně je spíš o přehazování dat z jedné hromady na druhou, případně jejich transformace – nejsou to žádné složité algoritmy, spíš propojování existujících komponent.
-
Díky ;).
Měl bych ještě jeden dotaz. V praxi - využívá se konfigurace přes xml/anotace/spring-boot?
Musím říct, že pote co jsem zjistil, jak je otravné nastavovat všechno to nastavení , tak jsem od toho chtěl utect, pak jsem vyzkoušel spring boot a kdyz se člověk může soustředit pouze na to programování, je to super.
-
Díky ;).
Měl bych ještě jeden dotaz. V praxi - využívá se konfigurace přes xml/anotace/spring-boot?
Musím říct, že pote co jsem zjistil, jak je otravné nastavovat všechno to nastavení , tak jsem od toho chtěl utect, pak jsem vyzkoušel spring boot a kdyz se člověk může soustředit pouze na to programování, je to super.
jak kde...
-
Díky ;).
Měl bych ještě jeden dotaz. V praxi - využívá se konfigurace přes xml/anotace/spring-boot?
Musím říct, že pote co jsem zjistil, jak je otravné nastavovat všechno to nastavení , tak jsem od toho chtěl utect, pak jsem vyzkoušel spring boot a kdyz se člověk může soustředit pouze na to programování, je to super.
jak kde...
Takže třeba xml se stále reálně používá? :O
-
Díky ;).
Měl bych ještě jeden dotaz. V praxi - využívá se konfigurace přes xml/anotace/spring-boot?
Musím říct, že pote co jsem zjistil, jak je otravné nastavovat všechno to nastavení , tak jsem od toho chtěl utect, pak jsem vyzkoušel spring boot a kdyz se člověk může soustředit pouze na to programování, je to super.
Pokud nemas specialni pozadavky, neni duvod nepouzit Spring Boot.
3rd party tartery nemusis pouzivat, je to jenom nadstavba.
Jinak pro konfiguraci se pouzivaji anotace v tvem kodu, application.yml pro spring boot related veci a konfiguracni classes pro knihovny.
Hlavni vyhoda konfiguracnich classes je, ze (pokud autor neni debil, co vyuziva konfiguracni class pro predavani hashmapy konfig atributu) te to vede ke spravne konfiguraci.
U XML jsem casto skoncil ve stavu, ze proste kurvafix se mi vracel null bean a v logu ani slovo. Konfiguracni class ti vetsinou rozumne rekne, co ji vadi.
-
s/tartery/startery/
-
Takže třeba xml se stále reálně používá? :O
Ono, ked z nejakeho dovodu potrebujes oddelit konfiguraciu komponentov od kodu a k tomu ju povedzme este externalizovat, tak je to vhodna cesta. Samozrejme, realne som potreboval take nieco len raz. Inac nevidim zmysel to tak robit.
Alebo dalsia moznost je, ked chce mat niekto konfiguraciu na ociach na jednom mieste. Este to ale nikto nechcel.
-
Takže třeba xml se stále reálně používá? :O
Ono, ked z nejakeho dovodu potrebujes oddelit konfiguraciu komponentov od kodu a k tomu ju povedzme este externalizovat, tak je to vhodna cesta. Samozrejme, realne som potreboval take nieco len raz. Inac nevidim zmysel to tak robit.
Alebo dalsia moznost je, ked chce mat niekto konfiguraciu na ociach na jednom mieste. Este to ale nikto nechcel.
XML se uz nepouziva je nahrazen @Configuration classama.
-
Měl bych ještě jeden dotaz. V praxi - využívá se konfigurace přes xml/anotace/spring-boot?
Používá se všechno, u starších aplikací, které vznikaly v době, kdy nebyla jiná možnost, než XML konfigurace, není potřeba to přepisovat – a Spring Boot se tam ani nepoužívá (protože v té době neexistoval, a dnes už není důvod ho tam přidávat, když je vše nakonfigurované i bez něj). A nějaký způsob konfigurace (XML, anotace nebo Java konfigurace – na tu jste zapomněl) se používá i se Spring Boot. Ten totiž jenom přidává smysluplné defaulty, ale jinak interně používá také kombinaci anotací a konfigurace v Javě.
Pokud se Springem začínáte, doporučuji Spring Boot používat a svou konfiguraci dělat pomocí anotací (jednoduchá statická konfigurace) a Java kódu (tam, kde je potřeba nějaká složitější logika). Musíte pak ale počítat s tím, že je komplikovanější ty defaulty Spring Bootu změnit – nejenom, že musíte znát, jak se daná věc nakonfiguruje ve Springu, ale ještě navíc musíte vědět, jak správně vypnout příslušnou autokonfiguraci ve Spring Bootu. Tím „správně“ myslím např. to, aby vámi dodaná beana nahradila tu automaticky vytvářenou Spring Bootem, protože na ní třeba závisí další automaticky vytvářené beany Spring Bootu, a ty už chcete ponechat v defaultním nastavení.
-
Takže třeba xml se stále reálně používá? :O
Ono, ked z nejakeho dovodu potrebujes oddelit konfiguraciu komponentov od kodu a k tomu ju povedzme este externalizovat, tak je to vhodna cesta. Samozrejme, realne som potreboval take nieco len raz. Inac nevidim zmysel to tak robit.
Alebo dalsia moznost je, ked chce mat niekto konfiguraciu na ociach na jednom mieste. Este to ale nikto nechcel.
XML se uz nepouziva je nahrazen @Configuration classama.
Dakujem, bez vas by som to nevedel.
-
Takže třeba xml se stále reálně používá? :O
Ono, ked z nejakeho dovodu potrebujes oddelit konfiguraciu komponentov od kodu a k tomu ju povedzme este externalizovat, tak je to vhodna cesta. Samozrejme, realne som potreboval take nieco len raz. Inac nevidim zmysel to tak robit.
Alebo dalsia moznost je, ked chce mat niekto konfiguraciu na ociach na jednom mieste. Este to ale nikto nechcel.
XML se uz nepouziva je nahrazen @Configuration classama.
Dakujem, bez vas by som to nevedel.
Prosim, rado se stalo.
A co se tyce XML/@Configuration externi konfigurace, jejim hlavnim ucelem je konfigurace 3rd party knihoven do kterych nechci zasahovat a ke kterym ani nemusim mit zdrojak.
-
Prosim, rado se stalo.
A co se tyce XML/@Configuration externi konfigurace, jejim hlavnim ucelem je konfigurace 3rd party knihoven do kterych nechci zasahovat a ke kterym ani nemusim mit zdrojak.
Ak externalizujem konfigurak, je mozne spravit rekonfiguraciu komponentov bez toho, aby som nieco kompiloval. V pripade, ze aplikacia je napisana ako skladacka, je xml-ko mozna cesta. (Pripadne by sa dala konfiguracia komponentov ulozit do databazy. Take nieco sa pouziva v jednej appke, co udrziavam, ale je to custom framework, nie spring. Ale v springu predpokladam, ze to tiez ide.)
Dakujem za rady, cenim si to.
-
Prosim, rado se stalo.
A co se tyce XML/@Configuration externi konfigurace, jejim hlavnim ucelem je konfigurace 3rd party knihoven do kterych nechci zasahovat a ke kterym ani nemusim mit zdrojak.
Ak externalizujem konfigurak, je mozne spravit rekonfiguraciu komponentov bez toho, aby som nieco kompiloval. V pripade, ze aplikacia je napisana ako skladacka, je xml-ko mozna cesta. (Pripadne by sa dala konfiguracia komponentov ulozit do databazy. Take nieco sa pouziva v jednej appke, co udrziavam, ale je to custom framework, nie spring. Ale v springu predpokladam, ze to tiez ide.)
Dakujem za rady, cenim si to.
Kdyz muzu, pomuzu.
XML je samozrejme cesta, ted (tak 7 let zpet) se stejna funkcionalita nahrazuje @Config classama.
https://www.mkyong.com/spring3/spring-3-javaconfig-example/
Dosahnes tim to same co XML a ma to spoustu moznosti navic, da se jednoduseji kontrolovat spravnost zadane konfigurace apod.
-
Prosim, rado se stalo.
A co se tyce XML/@Configuration externi konfigurace, jejim hlavnim ucelem je konfigurace 3rd party knihoven do kterych nechci zasahovat a ke kterym ani nemusim mit zdrojak.
Ak externalizujem konfigurak, je mozne spravit rekonfiguraciu komponentov bez toho, aby som nieco kompiloval. V pripade, ze aplikacia je napisana ako skladacka, je xml-ko mozna cesta. (Pripadne by sa dala konfiguracia komponentov ulozit do databazy. Take nieco sa pouziva v jednej appke, co udrziavam, ale je to custom framework, nie spring. Ale v springu predpokladam, ze to tiez ide.)
Dakujem za rady, cenim si to.
Kdyz muzu, pomuzu.
XML je samozrejme cesta, ted (tak 7 let zpet) se stejna funkcionalita nahrazuje @Config classama.
https://www.mkyong.com/spring3/spring-3-javaconfig-example/
Dosahnes tim to same co XML a ma to spoustu moznosti navic, da se jednoduseji kontrolovat spravnost zadane konfigurace apod.
Len nejak mi unika to, ako sa pri config classach vyhnem kompilacii. Ci mam u klienta rozbehat maven, ze tu si to skompilujte? Proste o to mi ide. Este mozno by sa dala pouzit nejaka vifikundacia cez groovy, o ktorej neviem ...
Ja jasne, ze je**m wiring priamo do komponentov a co sa neda, tak vytvaram beany/injektujem cez @Configuration lebo vacsinou to tak staci a nie som masochista. Zase aby mi tu nieco niekto nieco nepredkladal, co som nepovedal.
Dakujem este raz za rady.
-
Externalizovaná konfigurace je jedna z hlavních předností Spring Bootu, kdy pomocí externích properties/YAML souborů lze snadno konfigurovat věci, které jsou závislé na prostředí, například connection stringy, logování a spousta dalších. Navíc tyto property lze jednoduše mapovat (včetně validace) na typované objekty.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
To lze i efektivně kombinovat se Spring profily. Nicméně účel tototo je poněkud jiný, než externalizovaný XML config, který obsahoval především definici komponent a jejich wiringu. To je věc, kterou zpravidla nechcete bez rebuildu měnit, a proto se dnes definuje pomocí @Configuration tříd v Javě.
Konfigurační properties naproti tomu slouží pouze změně nastavení, které má smysl měnit bez rebuildu, a jejichž změna by neměla rozbít fungování aplikace (alespoň teoreticky, neplatí to úplně striktně).
-
Prosim, rado se stalo.
A co se tyce XML/@Configuration externi konfigurace, jejim hlavnim ucelem je konfigurace 3rd party knihoven do kterych nechci zasahovat a ke kterym ani nemusim mit zdrojak.
Ak externalizujem konfigurak, je mozne spravit rekonfiguraciu komponentov bez toho, aby som nieco kompiloval. V pripade, ze aplikacia je napisana ako skladacka, je xml-ko mozna cesta. (Pripadne by sa dala konfiguracia komponentov ulozit do databazy. Take nieco sa pouziva v jednej appke, co udrziavam, ale je to custom framework, nie spring. Ale v springu predpokladam, ze to tiez ide.)
Dakujem za rady, cenim si to.
Kdyz muzu, pomuzu.
XML je samozrejme cesta, ted (tak 7 let zpet) se stejna funkcionalita nahrazuje @Config classama.
https://www.mkyong.com/spring3/spring-3-javaconfig-example/
Dosahnes tim to same co XML a ma to spoustu moznosti navic, da se jednoduseji kontrolovat spravnost zadane konfigurace apod.
Len nejak mi unika to, ako sa pri config classach vyhnem kompilacii. Ci mam u klienta rozbehat maven, ze tu si to skompilujte? Proste o to mi ide. Este mozno by sa dala pouzit nejaka vifikundacia cez groovy, o ktorej neviem ...
Ja jasne, ze je**m wiring priamo do komponentov a co sa neda, tak vytvaram beany/injektujem cez @Configuration lebo vacsinou to tak staci a nie som masochista. Zase aby mi tu nieco niekto nieco nepredkladal, co som nepovedal.
Dakujem este raz za rady.
U konfig trid se kompilaci nevyhnes, lec nevim, proc by to melo necemu vadit.
To jako planujes u zakaznika rozzipovat JAR/WAR a modifikovat uvnitr Spring XML konfiguraci?
Externi aplikacni konfiguraci typu URL endpointu a nazvy DB schemat proste nacpu do application.yml a do konfiguracnich trid injektuju pres @Value, pripadne si pres @PropertySource definuju jiny propsfile, klidne externi mimo JAR/WAR, extremisti muzou vystavit centralni konfigurak na HTTP :)
A zakaznik pak muze externe hrabat pouze do konfigu, ktery je pro nej urcen, ne ze rozjebe cely Spring konfig.
https://www.baeldung.com/spring-value-annotation
https://blog.jayway.com/2014/02/16/spring-propertysource/
-
Externalizovaná konfigurace je jedna z hlavních předností Spring Bootu, kdy pomocí externích properties/YAML souborů lze snadno konfigurovat věci, které jsou závislé na prostředí, například connection stringy, logování a spousta dalších. Navíc tyto property lze jednoduše mapovat (včetně validace) na typované objekty.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
To lze i efektivně kombinovat se Spring profily. Nicméně účel tototo je poněkud jiný, než externalizovaný XML config, který obsahoval především definici komponent a jejich wiringu. To je věc, kterou zpravidla nechcete bez rebuildu měnit, a proto se dnes definuje pomocí @Configuration tříd v Javě.
Konfigurační properties naproti tomu slouží pouze změně nastavení, které má smysl měnit bez rebuildu, a jejichž změna by neměla rozbít fungování aplikace (alespoň teoreticky, neplatí to úplně striktně).
Tak nejak, byl jsi rychlejsi.
-
Externalizovaná konfigurace je jedna z hlavních předností Spring Bootu, kdy pomocí externích properties/YAML souborů lze snadno konfigurovat věci, které jsou závislé na prostředí, například connection stringy, logování a spousta dalších. Navíc tyto property lze jednoduše mapovat (včetně validace) na typované objekty.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
To lze i efektivně kombinovat se Spring profily. Nicméně účel tototo je poněkud jiný ...
Toto je normalna konfiguracia, ako vsade inde, to je prave ze chyba spring boot, ze dokonca aj property file sa dava default do jar-ka a "externalizovane" properties su specialna zalezitost.
-
Externalizovaná konfigurace je jedna z hlavních předností Spring Bootu, kdy pomocí externích properties/YAML souborů lze snadno konfigurovat věci, které jsou závislé na prostředí, například connection stringy, logování a spousta dalších. Navíc tyto property lze jednoduše mapovat (včetně validace) na typované objekty.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
To lze i efektivně kombinovat se Spring profily. Nicméně účel tototo je poněkud jiný ...
Toto je normalna konfiguracia, ako vsade inde, to je prave ze chyba spring boot, ze dokonca aj property file sa dava default do jar-ka a "externalizovane" properties su specialna zalezitost.
Propsfile v Jaru je az 6. v poradi v searchpath.
https://docs.spring.io/spring-boot/docs/1.0.1.RELEASE/reference/html/boot-features-external-config.html
-
Externalizovaná konfigurace je jedna z hlavních předností Spring Bootu, kdy pomocí externích properties/YAML souborů lze snadno konfigurovat věci, které jsou závislé na prostředí, například connection stringy, logování a spousta dalších. Navíc tyto property lze jednoduše mapovat (včetně validace) na typované objekty.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
To lze i efektivně kombinovat se Spring profily. Nicméně účel tototo je poněkud jiný ...
Toto je normalna konfiguracia, ako vsade inde, to je prave ze chyba spring boot, ze dokonca aj property file sa dava default do jar-ka a "externalizovane" properties su specialna zalezitost.
Propsfile v Jaru je az 6. v poradi v searchpath.
https://docs.spring.io/spring-boot/docs/1.0.1.RELEASE/reference/html/boot-features-external-config.html
Preferujem 7-me v poradi:
--spring.config.location="/etc/blabla/application.properties"
Tvorcovia tutorialov a roznych "skeleton" aplikacii preferuju to dat do jarka :)
-
Co byste mi doporučili udělat jako aplikaci ve springu, když bych to někde třeba i rád ukázal, co jsem v tom vytvořil?
Jsem schopen k tomu přidat HTML/CSS a i nějaký ten JS... ale neumím REST v tuto chvíili...
A prosím, berte v potaz to, že jsem nikdy nedělal profesionálně ve springu, ale umím docela dost dobře core javu. Ale prosím, aby to nebylo zase něco, co člověk těžko zvládne s minimem zkušeností.
Mockrát děkuji za nápady
-
No, tohle vymýšlení je někdy složitější než samotná realizace že :D