<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
