[Java lista] elvi kerdes: protected adattag

2009. Okt. 9., P, 10:48:40 CEST

Szia,

Mikor én desktop kis adatbázissal rendelkező alkalmazást fejlesztek,
akkor használok egy JavaDB-t, mellé tesztek egy JAR-t, definiálok egy
osztályt, odaírom, hogy @Entity, @Id azt mondom, hogy
entitymanager.persist, és lementi. Nem kell ide XML, ami minimális
kell, legenerálja a NetBeans.

Régen ez úgy történt, hogy telepítettem egy adatbázist, fogtam egy
adatbázis klienst, megírtam a create SQL-eket, írtam
PreparedStatement-eket, meg insert utasításokat, beállítgattam a
paramétereket, bazi sok kivételt (SQLException) kezeltem feleslegesen,
hol lezártam, hol nem a statement, resultset, connection-öket. Ja,
volt szülő gyerek kapcsolat? Akkor tranzakciót indítottam, és amennyi
típusú szülő gyerek kapcsolat, annyiszor ugyanez a móka, stb.

Komolyan, most fejlesztettem úgy desktop alkalmazást, hogy a
NetBeans-en kívül nem indítottam el más programot, és relációs
adatbázissal dolgozva egy SQL-t és XML-t sem láttam. De helyette 3
annotációt használtam.

Nem értem, hogy az XML-t annyit emlegeted, miért kell ilyen a JPA-hoz?

Validációval egyetértek, néha jó az ott a kódban.

István

2009/10/9  <istvan.ketler at lhsystems.com>:
> Szia,
>
>
>
> hát, szerintem egy egyszerű, kis adatbázis igényű alkalmazás esetén teljesen
> felesleges a JPA. Hiszek a KISS módszerben, és ha nem feltétlenül kell
> (értsd: nem látom közvetlen hasznát), akkor nem fogok mindenféle kiegészítő
> xml fájlokat írogatni, és teleannotálni a kódot. Ehelyett az adatellenőrzést
> simán beleteszem az accessor metódusokba. A kód sokkal olvashatóbb (az
> információ egyből ott van, nincs outsource-olva mindenféle leírókba).
> Egyszerű adatbázis esetén szerintem nem nagyon vannak adatosztályok a
> kódban, mert jobbára feleslegesek.  Ha nincs adatosztály, akkor a JPA
> pontosan mit is ad nekem? Ugyanezt tudom elmondani a bean validation esetén
> - ha nincs bean, akkor pontosan mit is validálok vele?
>
>
>
> Egyébként sem értem, mi abban a jó, hogy a kódból amit lehet, kiveszek, is
> bonyolult szintaktikájú, szerintem nehezebben olvasható XML állományokba
> dugdosom ezeket el. Bármit ha meg akarok tudni, akkor egy vagy több xml
> fájlt végig kell keresnem, hogy milyen megszorítások vannak arra az adott
> információra. Nagy alkalmazások, erős adatbázis kapcsolat esetén lehet
> értelme; rugalmasabbá teszi ezeket. De kisebb desktop alkalmazás esetén,
> ahol az adatkapcsolat csak kis része a történetnek, a nagyobb része a GUI
> (és esetleg az üzleti logika), ott nem látom ennek nagy hasznát. Az
> adatbázis kapcsolatot kiteszem egy-két osztályba, és azokon keresztül
> kommunikálok.Kellően rugalmas ez így is. Az xml leírókat pedig ilyenkor
> gyorsan elfelejtem. Minek szívassam magam mindenféle xml config fájlokkal,
> ha nem feltétlenül kell?
>
>
>
> Persze engem nem bánt, ha valaki ágyúval lődöz verébre, ha nem az általam
> felügyelt projektben teszi. De azért hiszek abban, hogy az architect a
> legjobb, nem pedig a legdivatosabb technológiát szereti választani. Nem
> használ valamit csak azért, mert "most az a menő".
>
>
>
> Igazából egy kérdésre keresném a választ. Lehet, hogy nincs igazam, és a JPA
> és/vagy bean validator tök jó. Azt kérném ezért, valaki magyarázza meg
> nekem, miért jobb annotációval és xml leírókkal ellenőrizni (és plusz
> jar-okat hozzácsapni a programhoz), mint simán betenni a validálást az
> accessor metódusokba. Mármint egyszerű, kis adatbázis hátterű desktop
> alkalmazások esetén. Ezt ugyanis nagyon nem értem.
>
>
>
> Üdvözlettel,
>
>
>
> Iván
>
> István Ketler
> Team Leader
>
> Lufthansa Systems Hungaria Kft.
> Airline Management Solutions
> Schedule & Revenue Management
> Alkotás u. 53.
> 1123 Budapest
> Hungary
>
> Tel: +36 1 887-2815
> Fax: +36 1 887-2977
>
> Room: MOM Park, Building A, Room 556
>
> e-mail: istvan.ketler at lhsystems.com
> Internet: www.LHsystems.hu
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria
> Kft, Budapest, Fövarosi Birosag 01-09-463417
> Geschaeftsfuehrung / Management Board: Monika Houck
>
> From: javalist-bounces at javagrund.hu [mailto:javalist-bounces at javagrund.hu]
> On Behalf Of Kristof Jozsa
> Sent: Thursday, October 08, 2009 2:04 PM
> To: javalist at javagrund.hu
> Subject: Re: [Java lista] elvi kerdes: protected adattag
>
>
>
> JPA és beanvalidation egyaránt használható java se-ben, ráadásul nem látom
> mi az összefüggés egy alkalmazás felülete és az általa használt adatbázis
> elérésére használt framework közt, felteszem semmi :)
>
> K
>
> 2009/10/8 <istvan.ketler at lhsystems.com>
>
> Szia,
>
> Hát, ha egy desktop alkalmazást írok, aminek nincs hatalmas adatbázis
> háttere, akkor azért valószínűleg nem fogok se JPA, se JSF fázist látni,
> Bean Validation Framework-öt sem használok, meg ilyenek.
>
> Van ám élet az ee-n kívül is! :)
>
> Üdvözlettel,
>
> Iván
>
> István Ketler
>
> Lufthansa Systems Hungaria Kft.
> Airline Management Solutions
> Schedule & Revenue Management
> Alkotás u. 53.
> 1123 Budapest
> Hungary
>
> Tel: +36 1 887-2815
> Fax: +36 1 887-2977
>
> Room: MOM Park, Building A, Room 556
>
> e-mail: istvan.ketler at lhsystems.com
> Internet: www.LHsystems.hu
>
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria
> Kft, Budapest, Fövarosi Birosag 01-09-463417
> Geschaeftsfuehrung / Management Board: Monika Houck
>
> -----Original Message-----
>
> From: javalist-bounces at javagrund.hu [mailto:javalist-bounces at javagrund.hu]
> On Behalf Of Elek Márton
> Sent: Thursday, October 08, 2009 10:06 AM
> To: javalist at javagrund.hu
>
> Subject: Re: [Java lista] elvi kerdes: protected adattag
>
> Én mondjuk azt a döntést is át tudnám érezni, hogy a validáció
> logikáját szedjük ki a konkrét osztályból, és ne a settelésnél
> validáljunk, hanem jól meghatározott validálási pontokon. Mondjuk Bean
> Validation Frameworkkel megannotálom az osztályt és be kattintom a
>
> propertyt, hogy a megfelelo JPA és JSF fázisokban automatikusan
>
> validáljon.
>
> m.
>
> 2009/10/8  <istvan.ketler at lhsystems.com>:
>
>> Jó kérdés. Ha protected helyett accessor metódusok vannak, akkor könnyen
>> megvalósítható az adatellenorzés. Protected adattag esetén erre nincs
>> lehetoség. Példa: az osztályom kezeli a barátnok listáját, de csak azokat a
>> lányokat akarom felvenni ide, akiknek barna a szeme. Ha az adattárolásra
>> használt lista protected láthatóságú, akkor a leszármazott osztályt semmi
>> nem kényszeríti erre a konvencióra, és elkezdi felvinni a kék szemu lányokat
>> is. Ettol az ajándékvásárló metódusom elromlik, mert nincs felkészülve az
>> eltéro szemszínre, és inkompatibilis színu ajándékokat kezd vásárolni - ergo
>> összeveszés prognosztizálható a barátnovel. Ha nem protected láthatóságú a
>> lista, akkor a getter visszatér egy unmutable listával, a setter pedig
>> átmásoláskor ellenorzi a konvenciót, és be nem tartása esetén goromba
>> kivétellel reagál.
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
>