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 > > >
