[Java lista] elvi kerdes: protected adattag

istvan.ketler at lhsystems.com istvan.ketler at lhsystems.com
2009. Okt. 9., P, 09:05:22 CEST 

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

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


 
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

 

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20091009/a0f40000/attachment-0001.html

További információk a(z) Javalist levelezőlistáról