Dobrý den, myslím si, že se správně mít stahu dělat všechno dobře a myslím si, že třeba i proto jsou čeští programátoři obecně poměrně žádaní. Děkuji za informaci o tom, jak to chodí v Anglii - ještě že pracuju v Čechách :-) V Anglii tedy asi perfekcionisté trpí :-)
Nechci mít validace úplně všude - chci je mít naopak jen a pouze na jediném místě. Nechť si je underlying framework vygeneruje na DB nebo ať nedovolí nic uložit do DB, pokud to neodpovídá validací. Totéž směřem výš - nechť framework využije znalostí (anotací) z business objektu a ověřuje co je uživatelem zadáváno. Vyzkouším to Spring Roo. Děkuji za tip! Libor Dne 23. května 2011 15:06 Stanislav Ošmera <[email protected]> napsal(a): > Myslim ze v cechach je prilisna snaha to delat "dobre". Tudiz je validace > uplne na vsechno a snaha delat aplikaci skutecne blbovzdornou. > Nekolik let ziju a pracuju v anglii a musim rict ze nejake validace tu > skoro nikdo neresi. Obcas se objevi neco malo na uzivatelske vrstve, ale > vicemene to konci na tom jestli ma byt policko vyplnene a nebo ne. V > databazich casto ani nenajdete constraint na cizi klice, proste vyuziva se > jen jako hromada kam se hazi data. > Ne ze bych to schvaloval, jsem databazista a kdyz jsem sem prisel tak mi > vstavali vlasy na hlave, ale proste nakonec jim to tu nejak funguje. > (setkavam se s aplikacema delanyma pro velke banky a pro utility company > jako treba british gas, takze to nejsou rozhodne aplikace delane amaterem > nekde na kolene). > To same s nejakym UML, to casto neznaji ani jako termin a kdyz jim ukazu > ERD diagram casti nasich databazi(jenom tohoo co jsem delal ja), tak se jim > to libi ze si pamatuji ze to mozna videli nekdy na skole. Kdyz od dodavatelu > chcete nejaka data tak je vubec uspech ze ve sloupci kde by meli byt cisla > nejsou nejake znaky (neni az tak uplne mimo kdyz maji vsechno ulozene jako > varchar). > > Co tim chci rict. Ze podporuju Jirku Hradila abyste se tim nezabyvali, > udelali jen naprosto nejnutnejsi validace a zbytek dodelavali klidne az > tehdy kdyz si o to zakaznik rekne. > > Standa. > > > > 2011/5/23 Libor Jelinek <[email protected]> > >> Já vím, že s Javou je to v posledních letech težké, protože je opravdu >> bohužel až příliš překomplikovaná. Přesto bych chtěl znát doporučení pro >> Javovský vývoj.... >> >> <flame>Všichni tak chvílíte Ruby a Rails, ale bohužel v nich stále nejde >> dělat desktopové aplikace (pokud vím) a další důvod, proč neuvažujeme o Ruby >> nebo Pythonu je prostě ten fakt, že jazyk není jen o nové syntaxi, ale celém >> ekosystému. A ten zvládnout trvá roky.</flame> >> >> Libor >> >> Dne 23. května 2011 13:58 Jiří Hradil <[email protected]> napsal(a): >> >> <flame>Jasne, rad se podelim o zkusenosti-ja pouzivam Ruby on Rails a >>> jejich validace. Tam to zmenim jen na 1 miste </flame>. >>> >>> Ted vazne - nemyslim, ze by bylo nutne delat constrainty primo v >>> databazi a jejim schematu treba na tu platnost data narozeni. To jen >>> zdrzuje a projekt je prevalidovan. Do databaze davam omezeni jen na >>> unikatni indexy a cizi klice, to staci. Zbytek kontroluju v aplikacni >>> logice. Uz si moc nevzpominam, jak se resily constrainty v JPA a >>> pripadne do ktere vrstvy to narvat, ale rozhodne by validace mela byt >>> soucasi modelu (objektu). Univerzalnost a externi definice treba v XML >>> je na pytel, protoze pak clovek hodinu premysli, kde mu to jeste vazne >>> a novacek umira, kdyz ma neco zmenit. >>> >>> Varuji taky pred prevalidaci. Rozhodne bych hned na zacatku nedaval >>> omezeni jako "datum narozeni musi byt v budoucnu", IC musi mit 8 >>> znaku, atd. To jsou tresnicky, ktere muzete resit, az vam bude >>> aplikace bezet. Setkal jsem se s hafo projekty a programatory, kteri >>> radeji resili regularni vyrazy na platnost RC a porad jim nejelo >>> ulozeni osoby do databaze. Cili za me - reste nejdriv naprosto >>> minimalni constrainty (PK, FK, unikatni indexy), dokoncete aplikaci a >>> dalsi validace dejte jako rozsireni. >>> >>> Jak to nejlip udelat v jave pri vsem tom balastu kolem >>> (JPA+Spring+Anotace+Hibernate) uz nevim, protoze jsem to zapomnel. Coz >>> je asi dukaz toho, ze to bylo tak blbe resene, ze mi to mozek smazal >>> :). >>> >>> Hezky den, >>> >>> Jirka Hradil >>> >>> 2011/5/23 Libor Jelinek <[email protected]>: >>> > Dobrý den! >>> > Chtěl bych trochu "společně" zauvažovat nad tématem z předmětu. V >>> každém >>> > projektu se vyskytují nějaké objekty. V první části mapujeme většinou >>> pomocí >>> > UML tzv. business objekty (faktura, zboží, osoba apod.). >>> > >>> > Tyto objektové třídy a vztahy poté mapujeme ručně nebo knihovnami jako >>> JPA >>> > na databázové tabulky. V méně případech mapovat nemusíme, protože >>> používáme >>> > objektové databáze (Bože, děkuji ti za ně :-)). >>> > >>> > V prezentační vrstvě (ať webové či swingové) máme nějaké formuláře nebo >>> > obecně GUI, které business objekty zobrazují, umožňuje vytvářet, >>> editovat a >>> > rušit (zkrátka CRUD operace). >>> > >>> > Naprosto běžné jsou nějaké omezení na vlastnosti objektů - IČ firmy >>> nesmí >>> > být text, RČ nesmí být prázdné, email musí obsahovat znak zavináč atd. >>> atd. >>> > Ač jsou tyto ověření stejné pro jakoukoli vrstvu aplikace, tak se v >>> každé až >>> > příliš často duplikují (v databázi jako SQL constrains, v aplikační >>> vrstvě >>> > kódem v Javě, v prezentační v JavaScriptu). >>> > >>> > Všechny vrstvy tak nějak opakují totéž. Sice se všechny techniky a >>> > frameworky stačí, aby to tak nebylo, ale i tak.... Když se při testech >>> > zjistí, že je možné zadat jako narození datum v budoucnu, pak se >>> obvykle >>> > přesto musí sáhnout do kódu databáze, Java classů a i podpůrných >>> validací ve >>> > webové vrstvě (když nemáme framework, tak zvlášť v webové server-side i >>> > client-side v JavaScriptu). >>> > >>> > Je nedostižným snem, aby se při takové situaci skutečně změnilo jen >>> jediné >>> > místo (jedno XML, anotace tříd, cokoli)? Chci se Vás proto zeptat, jak >>> k >>> > tomu přistupujete Vy, aby jste z jediného místa: >>> > >>> > - vygenerovat/změnit DB s příslušnými constrains (not null, délky >>> varcharů >>> > apod.) >>> > - když ještě budu u DB, tak aby by technologie dokázala provádět jen >>> delta >>> > změny v DB (tj. nevymazala tabulku a data, ale jen přidala/odebrala >>> sloupce) >>> > - vygenerovali/změnit Java classy >>> > - vygenerovat/změnit formuláře vč. kódu k validování vstupu uživatele >>> > >>> > Důraz kladu na nejen vygenerování, ale zejm. následné změny. >>> > >>> > Jako nejbližší tomuto ideálu se mi zdá následující kombinací >>> technologií >>> > (podotýkám, že mám jen teoretické zkušenosti) >>> > - mít model jako obyčejné POJO Java classy >>> > - olepit je JPA anotace entit, které vygenerují DB >>> > - do getterů/setter přidat business logiku (pravidla) >>> > - přidat ještě k fieldům/properties anotace z javax.validation >>> (JavaBeans >>> > Validations) pro ověřovací pravidla. >>> > >>> > Jedinou definicí modelu by byly Java classy ze kterých by se >>> vygenerovali >>> > databázové tabulky. Když je webovová vrstva v JSF, tak JSF umí využít >>> > JavaBeans Validations takéž. Když by byla prezentační vrstva Swing, tak >>> by >>> > asi bylo třeba něco dopsat. >>> > >>> > Ještě jako varianta mě napadá mít jako definici modelu pomocí XML >>> schémat, >>> > ale by mi připadalo jako příliš komplikované (à la EJB) oproti modelu s >>> > POJO. >>> > >>> > Chtěl bych se zeptat těch, kteří se něčím takovým již potýkali/řešeli, >>> zda >>> > zmíněné technologie (nebo obdobné), považujete za vhodné (zda cesta s >>> JPA a >>> > JavaBeans Validation je ta správná). Jestli se můžete dělit se svými >>> > zkušenostmi... >>> > >>> > Díky předem za všechny příspěvky. >>> > >>> > Libor >>> > >>> >> >> > > > -- > Stanislav Ošmera > Work: +44 (0)2075 980 343 > Cell: +44 (0)7758 968 220 > Skype: sosmera ICQ:149634231 > Jabber: [email protected] >
