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]
