Ahoj,
zkus se pripadne podivat i na Spring Roo. Celkem me to nadchnulo.
Entity definujes 1x jako POJO a data access metody stejne jako web
controller + view si muzes nechat dogenerovavat automaticky.
Pokud zmenis POJO Entitu, tak roo zmeny aplikuje i do generovanych
casti. Tam kde chces si muzes generovane casti (metody) napsat sam, na
ty pak Roo nesaha. Podobne to funguje i pro vygenerovane View, pokud
zmenis napr. TextField, ktery se vztahuje k nejakemu atributu Entity,
tak ho Roo prestane prepisovat.
Nedavno bylo Roo na CZJUGu. Video z toho je v archivu
http://www.youtube.com/czjug
Petr
On 23.5.2011 13:27, Libor Jelinek wrote:
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
