Hoi,
Adott egy nezet/lekerdezes/tabla, amit meg akartok jeleniteni, akkor Java-ban az ehhez szukseges modellt mivel generaljatok? Ez legtobbszor eleg statikus dolog. Qt es Visual Studioban-ban megadod a lekerdezest es gyonyoruen a komplett MVC-t megcsinalja magatol. Egy tablas nezet eseteben meg a foreign keyekhez tartozo ertekek is megjelennek legordulo comboboxban.
Valami ilyesmire gongoltam: http://sql2java.sourceforge.net/
Legjobb persze egy Eclipse/NetBeans plugin lenne, connect to database -> execute query -> generate model.
udv,
Gabor
- 1701 megtekintés
Hozzászólások
Igazabol az a bajom, hogy egy lekerdezes attributumainak a tipusa egyreszt nem valtozik, masreszt az elejetol fogva egyertelmu, h milyen java tipusoknak felel meg. Eleg unalmas mindig kezzel legeneralni a hozza tartozo TableModel-eket.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
mindenki kézzel csinálja?!
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
bevallom en igen :-)
vagy ORM -el szoktam generaltatni a semat, persze kezzel atnezem a logot, hogy nem csinalt-e hulyeseget, de parezer ilyenbol 1x se volt gaz, max en felejtettem le vmi annotaciot.. :)
- A hozzászóláshoz be kell jelentkezni
Van ingyenes ORM ami ezt tudja?
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
ORM összehasonlítás: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html ÉS némi leírás.
Szerintem iBATIS a te esetben jobb, lehet sok is...
- A hozzászóláshoz be kell jelentkezni
Valóban, nem akarok komolyabb sémákat, se XML perzisztenciát, se UML -> [adatbázis, osztály, modell] átalakítást. Közvetlenül szeretném továbbra is a relációs adatbázist használni.
Olyat szeretnék, mind amit a Visual Studio DataSet-je tud: felveszek egy dataset-et, ami később MVC-ben egy modell motorja tud lenni.
És megadok neki egy lekérdezést, pl. select * from A join B on x , aminek eredménye lesz [a,x,b] oszlopokból álló tábla. Ezeknek az oszlopoknak a típusa nem változik, így azonnal generálható belőle a modell. Ha a lekérdezés pedig csak egy táblára/írható nézetre vonatkozik, akár updatelhető modell is rögtön generálható.
Vagy mint Qt-ben a QSqlQueryModel, ami egy lekérdezés eredményével felparaméterezhető, és kapásból megvalósítja a modellt és a hozzá tartozó interfacet. Valami ilyesmire gondoltam: http://www.java2s.com/Code/Java/Database-SQL-JDBC/RowSetModelbasedonTab… , de kicsit szofisztiáltabbra.
Nem bonyolult dolog, de ha sok táblát akar az ember használni, elég unalmas kézzel csinálni a sémát. Redundáns a sémát az adatbázisban és a programban is definiálni. Ha pedig a séma bonyolultabb, akkor még mindig lehet kézzel hackelni, vagy származtatni/proxy patternt használni, ha mondjuk szűkíteni akarjuk az elfogadott elemeket.
Pl. qt -ben:
(...)
QSqlQuery query("select * from A join B on x");
m = new QSqlQueryModel(this);
m->setQuery(query);
table->setModel(m);
(...)
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Megint máshogyan megfogalmazva, miért nincs egyszerű mód egy RowSet-et vagy ResultSet-et TableModel-ként látni?
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
ezeket nézd meg hátha találsz valamit :)
- A hozzászóláshoz be kell jelentkezni
nice :)
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
Gondolom ilyesmire gondoltál.
De ha írnál sajátot akkor DAO pattern-re szavazok + akkor a saját TableModel-ed.
u.i.: NagyZ, EJB3 in Action rocks! Köszi az ajánlást. Már csak bekéne szerezni valamelyik .com-ról :S
- A hozzászóláshoz be kell jelentkezni
Hibernate? Van hozzá Eclipse/NetBeans plugin is.
- A hozzászóláshoz be kell jelentkezni
-1
+1 eclipselink, ez a jpa2es refimplementacio, egesz jo, en ezt hasznalom prodban, patchelve
- A hozzászóláshoz be kell jelentkezni
Meg tudnád ezt indokolni?
Nem kötözködni akarok, egyszerűen csak nem ismerem az eclipselink-et és kíváncsi vagyok.
- A hozzászóláshoz be kell jelentkezni
volt uegy a hibernate, joval az ejb3 spec elott.
aztan sok jo otlet volt ORM szinten benne, a Sun meg szerette volna ha jokis ORM van a refimp melle. igy a JPA1.0 az nagyjabol ~hibernate, a glassfish melle (ami meg a java ee 5 refimp) meg odacsomagoltak az oracle toplink cuccanak butitott valtozatat (toplink essentials).
oracle megunta, hogy ket agat kell karbantartania, igy kidobta az egesz suite kodjat, es odaadta az eclipse projektnek (de egy Dave nevu oracles srac vezeti most is a projektet) - ez lett az eclipselink.
aztan azota hivatalosan az a JPA2.0 referenciaimplementacio.. :)
amugy ez hitvallas kerdese... spring vs ejb, jboss vs glassfish, hibernate vs akarmimas:)
- A hozzászóláshoz be kell jelentkezni
Köszi!
- A hozzászóláshoz be kell jelentkezni
közben olvasgattam, és kezd összeállni bennem a kép, hogy a perzisztencia frameworkök pont erről szólnak
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni