<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 <ljeli...@virtage.com>: > 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 >
