Hirdetés
- AMD Navi Radeon™ RX 9xxx sorozat
- Apple MacBook
- Projektor topic
- Azonnali VGA-s kérdések órája
- SSD kibeszélő
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- 3D nyomtatás
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Amlogic S905, S912 processzoros készülékek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Új hozzászólás Aktív témák
-
Be tudnátok dobni érdekes/nem érdekes kérdéseket amelyeket állásinterjún kaptatok? (Java/logika)
pl ilyenekre is gondolok: Hány zongorahangoló van Budapesten?
Köszi!
Jaj, ne, az ilyen "miért kerekek a csatornafedelek", "hány tenniszlabda fér egy jumbo jetbe" meg hasonló kérdések annyira kontraproduktívak...
-
bucsupeti
senior tag
Ez mondjuk az IDE consoljára nem biztos, hogy hatássas lesz. Rondábbnak tűnő, de platformfüggetlen megoldás jó sok új sort kiírni.
norbert1998: Ha System.err -re írsz System.out helyett azt remélhetőleg pirossal írja.
windowsokon nem tudom most éppen mi a működés, de linuxon szerintem is az üres sorok kiiratása a jó módszer. -
WonderCSabo
félisten
if os == windows {
Runtime.getRuntime.exec("cls");
} else if os == *nix {
Runtime.getRuntime.exec("clear");
} else {
Runtime.getRuntime.exec("akármi, ami konzolt töröl....");
}Amolyan pszeudóféleképpen
-
norbert1998
nagyúr
if os == windows {
Runtime.getRuntime.exec("cls");
} else if os == *nix {
Runtime.getRuntime.exec("clear");
} else {
Runtime.getRuntime.exec("akármi, ami konzolt töröl....");
}Amolyan pszeudóféleképpen
Köszi, holnap megnézem
-
Aethelstone
addikt
Olyanra gondoltam, amit a programkódba lehet írni, de akkor gondolom ilyen nincs. Mindegy, köszönöm
Olyan van esetleg, hogy amit oda kiír a NetBeans, azt vastgított vagy dőlt vagy valamilyen kiemelt betűvel tegye egy-egy sornál?
if os == windows {
Runtime.getRuntime.exec("cls");
} else if os == *nix {
Runtime.getRuntime.exec("clear");
} else {
Runtime.getRuntime.exec("akármi, ami konzolt töröl....");
}Amolyan pszeudóféleképpen
-
norbert1998
nagyúr
Jobb gomb az Output ablakban, majd Clear, vagy nyomatsz egy Ctrl+L-t...
Olyanra gondoltam, amit a programkódba lehet írni, de akkor gondolom ilyen nincs. Mindegy, köszönöm
Olyan van esetleg, hogy amit oda kiír a NetBeans, azt vastgított vagy dőlt vagy valamilyen kiemelt betűvel tegye egy-egy sornál?
-
Sk8erPeter
nagyúr
Bocsánat. NetBeans IDE
-
norbert1998
nagyúr
A konzol/terminál tartalmát szeretnéd törölni? Mert Windows-on az a cls bepötyögésével, majd Enterrel megoldható, Linuxnál a clear kulcsszóval.
(Már ha jól értettem a kérdésedet...)Hogy kell elképzelni ezt, hogy mindent konzolon csináltok? nano, mcedit (most ezek Linux-eszközök, de mindegy), vim (bár ezt kétlem), ilyesmik használatával szerkesztitek a kódot?
(#7288) floatr:
A Java-fejlesztőknek nem a hosszú távú támogatás jár a fejében? Ez így furán hangzik.
Bocsánat. NetBeans IDE
-
Sk8erPeter
nagyúr
Lenne még egy kérdésem. Mivel grafikusan még nem programozunk, hanem mindent konzolon csinálunk, így egy idő után cseszett bonyolítottá válik a konzol. Lehet valamivel olyasmit csinálni, hogy a konzol tartalmát töröljük?
Egy hierarchikus switch-case menürendszerről lenne szó, összesen 22 választható elemmel, egymásba szinteződve, javarészt.A konzol/terminál tartalmát szeretnéd törölni? Mert Windows-on az a cls bepötyögésével, majd Enterrel megoldható, Linuxnál a clear kulcsszóval.
(Már ha jól értettem a kérdésedet...)Hogy kell elképzelni ezt, hogy mindent konzolon csináltok? nano, mcedit (most ezek Linux-eszközök, de mindegy), vim (bár ezt kétlem), ilyesmik használatával szerkesztitek a kódot?
(#7288) floatr:
A Java-fejlesztőknek nem a hosszú távú támogatás jár a fejében? Ez így furán hangzik. -
norbert1998
nagyúr
-
floatr
veterán
Szerintem tanulmányozd magának a Javának a forráskódját, rá fogsz csodálkozni, hogy TELE van a break kulcsszó használatával ciklusokon innen és túl is.
Na nem mintha azt akarnám sugallni, hogy az biztos a világ legjobb kódjainak gyűjteménye, de valószínűsíthetően nem kókler kretének írják, akik azért használnak breaket, mert buták, és nem tudnak kódolni.Sajnos láttam már miket műveltek a forrásban
Látszik hogy nagy code wariorok voltak a szerzők, de nem is a hosszútávú támogatás járt a fejükben, amikor megszülték a művüket. De ez elmondható elég sok frameworkről is. -
WonderCSabo
félisten
Offensive programming nem is olyan hülyeség.
-
Sk8erPeter
nagyúr
Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
Szerintem tanulmányozd magának a Javának a forráskódját, rá fogsz csodálkozni, hogy TELE van a break kulcsszó használatával ciklusokon innen és túl is.
Na nem mintha azt akarnám sugallni, hogy az biztos a világ legjobb kódjainak gyűjteménye, de valószínűsíthetően nem kókler kretének írják, akik azért használnak breaket, mert buták, és nem tudnak kódolni. -
Hát néha a klingonos sem az. Nemrég fordult elő, hogy valaki addig kavart az SVN branch-ekkel, hogy olyan is LIVE-ba ment, aminek nem kellett volna. Szó szerint nem release volt, de még csak nem is szabadjára engedték, hanem megszökött. A QA csoport véres hullái rész meg csak azért maradt el, mert mire fizikailag odaért volna a PO, addigra lecsillapodott
-
Aethelstone
addikt
Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
Ugyan, iterátor
Az igazi programozó break-et használ (bár mi már messze vagyunk a programozótól...mi csak amolyan alkalmazás-fejlesztők vagyunk ) -
floatr
veterán
"Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést."
Nem véletlenül mondtam az előbb a foreach-ciklust, még ki is hangsúlyoztam, hogy nem sima for ciklusról van szó. Magyarul nincs ciklusfeltétel, kész. Cserébe magának a ciklusnak a "fejléce" szebb tud lenni, nincs szükség indexelésre, és így tovább, hát ugye a foreach-ciklus szépsége. Berakva egy if(...) { break; }-et (nyilván szépen tördelve) semmivel sem lesz rondább, ha az nem valahol egy túl nagyra hízott ciklustörzs (eleve már itt kezdődik a gond) közepén helyezkedik el valahol, teljesen egyértelmű a ciklus megszakítása, szóval nem igazán tudom felfogni, nálad miért nem menne át a kódreview-n. Erre mondtam, hogy sokszor nevetségesek ezek a teljesen rugalmatlan "szabályok". Vannak általános irányelvek, amiktől rondább vagy szebb lesz egy kód, de általánosítani itt is tök felesleges. Sima for ciklusnál teljesen érthető, egy foreach-nél nem, nem lesz tőle rondább a kód, ha a kódot olvasó emberke számára nem egyértelmű, hogy ott bizony valamitől függően kilépés lesz a ciklusból, hát akkor nem a kód írójával van baj. Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
-
norbert1998
nagyúr
Teljesen érthető for-ciklusnál, de én még mindig foreach-ről beszélek, gondolom majd azt is fogjátok tanulni.
-
Sk8erPeter
nagyúr
Ugyanazt javasolta, mint ti. Extra. Console. Readint. [és ezt rendesen formázva, csak buta a t9]
Sk8erPeter: azért kéri így, hogy megtanuljuk a for, while és do-while ciklusokat használni.
Tényleg lehet break-kel kocolni, alairom, csak az adott esetben teljesen működőképes volt.
Köszönöm a segítséget
Teljesen érthető for-ciklusnál, de én még mindig foreach-ről beszélek, gondolom majd azt is fogjátok tanulni.
-
norbert1998
nagyúr
Akkor ha bármilyen negatív dolog lenne ezzel kapcsolatban.
Ugyanazt javasolta, mint ti. Extra. Console. Readint. [és ezt rendesen formázva, csak buta a t9]
Sk8erPeter: azért kéri így, hogy megtanuljuk a for, while és do-while ciklusokat használni.
Tényleg lehet break-kel kocolni, alairom, csak az adott esetben teljesen működőképes volt.
Köszönöm a segítséget
-
Sk8erPeter
nagyúr
Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést. Nyilván lesz olyan eset, amikor nagyon nyakatekert lenne break nélkül, de sokszor csak rontja a support-ot.
"Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést."
Nem véletlenül mondtam az előbb a foreach-ciklust, még ki is hangsúlyoztam, hogy nem sima for ciklusról van szó. Magyarul nincs ciklusfeltétel, kész. Cserébe magának a ciklusnak a "fejléce" szebb tud lenni, nincs szükség indexelésre, és így tovább, hát ugye a foreach-ciklus szépsége. Berakva egy if(...) { break; }-et (nyilván szépen tördelve) semmivel sem lesz rondább, ha az nem valahol egy túl nagyra hízott ciklustörzs (eleve már itt kezdődik a gond) közepén helyezkedik el valahol, teljesen egyértelmű a ciklus megszakítása, szóval nem igazán tudom felfogni, nálad miért nem menne át a kódreview-n. Erre mondtam, hogy sokszor nevetségesek ezek a teljesen rugalmatlan "szabályok". Vannak általános irányelvek, amiktől rondább vagy szebb lesz egy kód, de általánosítani itt is tök felesleges. Sima for ciklusnál teljesen érthető, egy foreach-nél nem, nem lesz tőle rondább a kód, ha a kódot olvasó emberke számára nem egyértelmű, hogy ott bizony valamitől függően kilépés lesz a ciklusból, hát akkor nem a kód írójával van baj. -
#39560925
törölt tag
A label már durva, de egy breakkel semmi baj. Nyilván célszerűbb valami do while vagy while szerkezetet felépíteni, ha az ember ki akar idő előtt lépni, de szerintem a for loop-ban elkövetett breakkel sincs semmi baj. Ha az ember módjával használja. Persze háromezer if the else és switch szerkezetekben 678 break nem szép....
-
floatr
veterán
Mi a baj a break-kel úgy általában? Már a for loop kapcsán...
-
Aethelstone
addikt
-
#39560925
törölt tag
Mi a baj a break-kel úgy általában? Már a for loop kapcsán...
-
Aethelstone
addikt
A wildcard-os import egyszerűen bad practice. Néha gyorsabb megoldani valamit vele, de a mai IDE-k támogatják az import sorok generálását is; beírsz valamit, aztán vagy magától megtalálja, hogy mit kell beszúrni, vagy rákérdez, hogy melyiket a sok közül szeretnéd.
Viszont a break-es témában igaza volt, hogy azzal össze lehet kócolni a kódot rendesen.
(#7270) Sk8erPeter háááát... nálam a kódreview-n nem menne át
Mi a baj a break-kel úgy általában? Már a for loop kapcsán...
-
floatr
veterán
Levonni nem hiszem, hogy levonnak. Mikor tz-be while helyett for ciklust tettem if-es break-el,annyit mondott, hogy te [legyen a vezeteknevem mondjuk] kovács! Megmondtam, hogy órán ne breakelj. Most nézzétek meg, ti itt dolgozatot írtok, ez meg itt breakel...
Egyszóval, nem fog érte megölni, jo fej ürge. De mindjárt beérek, megkérdezem tőle.
A wildcard-os import egyszerűen bad practice. Néha gyorsabb megoldani valamit vele, de a mai IDE-k támogatják az import sorok generálását is; beírsz valamit, aztán vagy magától megtalálja, hogy mit kell beszúrni, vagy rákérdez, hogy melyiket a sok közül szeretnéd.
Viszont a break-es témában igaza volt, hogy azzal össze lehet kócolni a kódot rendesen.
(#7270) Sk8erPeter háááát... nálam a kódreview-n nem menne át
-
Sk8erPeter
nagyúr
Levonni nem hiszem, hogy levonnak. Mikor tz-be while helyett for ciklust tettem if-es break-el,annyit mondott, hogy te [legyen a vezeteknevem mondjuk] kovács! Megmondtam, hogy órán ne breakelj. Most nézzétek meg, ti itt dolgozatot írtok, ez meg itt breakel...
Egyszóval, nem fog érte megölni, jo fej ürge. De mindjárt beérek, megkérdezem tőle.
Remélem, azért nem szól be, ha egy foreach-ciklusnál (nem sima for) adott esetben használsz breaket... néha vannak emberkék, akik kitalálnak ilyen "szabályokat", hogy legyen mivel lefoglalni magukat.
A kód olvashatóságát pedig ez például nem rontja. -
WonderCSabo
félisten
Levonni nem hiszem, hogy levonnak. Mikor tz-be while helyett for ciklust tettem if-es break-el,annyit mondott, hogy te [legyen a vezeteknevem mondjuk] kovács! Megmondtam, hogy órán ne breakelj. Most nézzétek meg, ti itt dolgozatot írtok, ez meg itt breakel...
Egyszóval, nem fog érte megölni, jo fej ürge. De mindjárt beérek, megkérdezem tőle.
-
norbert1998
nagyúr
Ne viccelj, ha emiatt levonnak a megoldásodból, akkor hagyd ott azt az intézményt...
-
Sk8erPeter
nagyúr
Ez nagyon faszányos, köszi!
-
WonderCSabo
félisten
-
WonderCSabo
félisten
Úgy érted, hogy például:
int fomenu=extra.Console.readInt("sg");
?WonderCSabo: Ez is megoldható, de mindig, kivétel nélkül .*;-al operáltunk, és nem tudom, mennyire lenne díjazva, ha változtatnék.
-
Ursache
senior tag
És akkor a program elejére nem kell olyan, hogy import extra, vagy hasonló?
-
norbert1998
nagyúr
-
Ursache
senior tag
Úgy érted, hogy például:
int fomenu=extra.Console.readInt("sg");
?WonderCSabo: Ez is megoldható, de mindig, kivétel nélkül .*;-al operáltunk, és nem tudom, mennyire lenne díjazva, ha változtatnék.
-
norbert1998
nagyúr
-
WonderCSabo
félisten
Üdv!
Lenne egy kis gondom. Beadandót kell csinálnunk java-bol, de adódott egy elég nagy gondom rögtön az első soroknál.
Mi bevitelhez az extra.Console-t használjuk, viszont kellene a FileWriter is abba a programba, meg úgy eléggé sokminden a java.io-ból is. Úgy rémlik, ezzel semmi gond nem volt, mintha még írtunk is volna ilyen kis programot a suliban, de nekem nem megy.
Beírom, ahova szokás, hogy
import java.io.*;
import extra.*;
És amikor az első sorba belekezdenék:
int fomenu=Console.readInt("blablabla");
Fogja magát, és kiirja, hogy ütközés van a java.io.* és az extra.* között, mert mindkettőben van Console osztály.
Mit lehet tenni ezellen?Osztálytársaknak is mind működik, hiszen, van, aki már be is fejezte a programját, és ennek a két dolognak benne kell lennie.
-
Ursache
senior tag
Üdv!
Lenne egy kis gondom. Beadandót kell csinálnunk java-bol, de adódott egy elég nagy gondom rögtön az első soroknál.
Mi bevitelhez az extra.Console-t használjuk, viszont kellene a FileWriter is abba a programba, meg úgy eléggé sokminden a java.io-ból is. Úgy rémlik, ezzel semmi gond nem volt, mintha még írtunk is volna ilyen kis programot a suliban, de nekem nem megy.
Beírom, ahova szokás, hogy
import java.io.*;
import extra.*;
És amikor az első sorba belekezdenék:
int fomenu=Console.readInt("blablabla");
Fogja magát, és kiirja, hogy ütközés van a java.io.* és az extra.* között, mert mindkettőben van Console osztály.
Mit lehet tenni ezellen?Osztálytársaknak is mind működik, hiszen, van, aki már be is fejezte a programját, és ennek a két dolognak benne kell lennie.
-
norbert1998
nagyúr
-
WonderCSabo
félisten
A tömb eleme null, ezt már kiderítettem
-
Mivel nem osztottad meg az egész kódot, ezért a kövi lehet:
maga a tömb eleme null VAGY
a rand változó nullEzt egy másodperc alatt ki lehet deríteni debuggerrel.
-
WonderCSabo
félisten
Ez lemaradt, még előtte van:
Karakter[] elsoJatekos = new Karakter[karakterSzam * 2];
Karakter[] masodikJatekos = new Karakter[karakterSzam * 2];
int karakterSzam = 0, karValEgy = 0, karValKetto = 0; -
Kötelező program és nem szeretném, ha véletlenül valaki használná és kiderülne.
A 86. sorban ír ki hibát
-
szcsaba1994
tag
-
Ursache
senior tag
Sziasztok!
Van egy file, aminek a tartalma egy szó(objektum típusa), utána pedig 4 attribútum, amik az objektum konstruktorába kerülnek.
Ebből a file-ból szertnék beolvasni, gyakorlatilag eg játékállást betöltve.
Ha az elején 2-es gombot nyomom le, akkor olvassa be a fájból, ha az egyest akkor teljesne új játékot kell kezdeni (ez gond nélül meg is van)Kb így néz ki:
Tipus[] tombEgy;
Tipus[] tombKetto;
if(gomb==2){
betoltes(tombEgy, fileEgy);
betoltes(tombKetto, fileKetto);
}
if(gomb==1){
tombEgy = new Tipus[db];
tombKetto = new Tipus[db];
feltolt(tombEgy);
feltolt(tombKetto);
}Mikor a betöltöttel szeretnék játszani, kapok egy NullPointerExceptiont akkor, amikor a tombKetto-t használnám először
Mi lehet a gond?
-
szcsaba1994
tag
-
lyaly
Itt azért elkövettél pár olyan dolgot, amivel alá lehet vágni egy kitervelt rendszernek. Egyrészt - bár ismétlem magam - ez a generált kód... szerintem jobban jársz, ha egy kicsit veszed a fáradtságot, és megtanulod magad legyártani a kódot a táblák alapján, vagy fordítva.Ha már generáltál valamit adatbázis valami alapján, akkor nagyon észnél kell lenni, hogy mibe túrsz bele. Itt épp azzal babráltál, amivel nem kéne. Mellesleg nekem amiatt gyanús a metódusra akasztott annotációval, mert olyan, mintha félig, vagy egyáltalán nem értené, hogy máshogy akarod elnevezni. Ha már annotálod a cuccot, akkor az átláthatóságot is növeli, ha a mezőkre aggatod őket.
Az@Id mellé még odatenném a @GeneratedValue-t is, mert ezzel a legtöbb adatbázisnál tud auto increment-es típust használni.
-
Egyébként az MpaaRatings-zel ugyan ezt csinálja. Ott is nem létező, id oszlopot keres az adatbázisban. Ezekről tudni kell, hogy én nyomtam alter table-t utólag a táblákon, hogy legyen elsődleges kulcs bennük. Pl:
alter table movietime2.movies2actors add m2aid int primary key auto_increment;Ez azóta is jó egyébként, a movies2actors kapcsolótáblát boldogan tudom használni.
Ha explicit megadom az MpaaRatingsEntity-hez, hogy mi a join table és mik a join columnok, akkor se jó:
@JoinTable(name = "mpaaratings", catalog = "movietime2", schema = "",
joinColumns = @JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false),
inverseJoinColumns = @JoinColumn(name = "mpaaratingsId", referencedColumnName = "mpaaratingsId", nullable = false))"Missing column: mpaaratings_id in movietime2.mpaaratings"
Holott meg:
-
"Nekem a hibaüzenetből eleve az gyanús, hogy a táblában más néven keresi az ID-t, mint ahogy deklaráltad volna."
Ok, de mire gyanakszol?
Miért "ahogy deklaráltad volna"? Nem volna, hanem így van deklarálva: genreId. Meg is van adva neki, hogy így keresse.
"A helyedben én az @Id és @Column annotációkat nem a metódusokra tenném."
Nem én tettem, az Idea volt. Tökéletesen működik minden, ha kiveszem a GenresEntity osztályt."Az meg a másik, hogy ha csak nem muszáj, én nem babrálnám a hibernate saját elnevezési stratégiáját."
Ezt kifejtenéd kérlek bővebben? Mire gondolsz?
Ha az entitások és az attribútimaik neveire gondolsz, akkor azok 2 okból alakultak így:
1) adatbázisban a nevek
2) Ideában a Generate persistence mapping by database schema wizardbólEgyébként az MpaaRatings-zel ugyan ezt csinálja. Ott is nem létező, id oszlopot keres az adatbázisban. Ezekről tudni kell, hogy én nyomtam alter table-t utólag a táblákon, hogy legyen elsődleges kulcs bennük. Pl:
alter table movietime2.movies2actors add m2aid int primary key auto_increment;Ez azóta is jó egyébként, a movies2actors kapcsolótáblát boldogan tudom használni.
Ha explicit megadom az MpaaRatingsEntity-hez, hogy mi a join table és mik a join columnok, akkor se jó:
@JoinTable(name = "mpaaratings", catalog = "movietime2", schema = "",
joinColumns = @JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false),
inverseJoinColumns = @JoinColumn(name = "mpaaratingsId", referencedColumnName = "mpaaratingsId", nullable = false))"Missing column: mpaaratings_id in movietime2.mpaaratings"
Holott meg:
-
Nekem a hibaüzenetből eleve az gyanús, hogy a táblában más néven keresi az ID-t, mint ahogy deklaráltad volna. A helyedben én az @Id és @Column annotációkat nem a metódusokra tenném.
Az meg a másik, hogy ha csak nem muszáj, én nem babrálnám a hibernate saját elnevezési stratégiáját.
Az org.hibernate.cfg.DefaultComponentSafeNamingStrategy nekem eddig minden problémámat megoldotta -
Intellij Idea tette bele a generálás során. Ezen én is gondolkodtam, de mivel nem fogok hozzájuk nyúlni, egyelőre nem akartam bántani őket.
"MoviesEntity -ben hol a characters mappelése?"
Látod, a hsz-ben, de itt van mégegyszer:
@OneToMany(mappedBy = "movie")
public List<Movies2ActorsEntity> getCharacters() {
return characters;
} -
-
Először is itt egy működő példa |Movies2Actors| *----1 |Movies|:
MoviesEntity class:
@JsonIgnore
private List<Movies2ActorsEntity> characters;
@JsonIgnore
private List<GenresEntity> genres;
...
@OneToMany(mappedBy = "movie")
public List<Movies2ActorsEntity> getCharacters() {
return characters;
}
@OneToMany(mappedBy = "movie")
public List<GenresEntity> getGenres() {
return genres;
}Movies2ActorsEntity class:
private int m2aid;
private int movieid;
private int actorid;
private String asCharacter;
private ActorsEntity actor;
private MoviesEntity movie;
...
@Id
@Column(name = "m2aid", nullable = false, insertable = true, updatable = true)
public int getM2aid() { return m2aid; }
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
}És akkor a |Genres| *----1 |Movies|
GenresEntity:
private int movieid;
private String genre;
private int genreId;
@JsonIgnore
private MoviesEntity movie;
...
@Id
@Column(name = "genreId", nullable = false, insertable = true, updatable = true)
public int getGenreId() {
return genreId;
}
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
} -
De, persze, ezt a MoviesEntity-vel joinolom. Azóta az is belekerült az SO kérdésbe. De a kérdés inkább az, hogy a hibernate honnan szedi ezt a genre_id-t, amikor elvileg helyesen fel van annotálva, hogy genreId van az adatbázisban. MoviesEntity és Movies2ActorsEntity között ugyan ilyen OneToMany kapcsolat van és működik, ahhoz képest semmit sem csináltam másképp.
-
Aethelstone
addikt
Amit eddig láttam, az alapján azt tudom mondani, hogy amint a projekt megéri a telepítési fázist kiderül, hogy bármilyen generált kódról is van szó, a fejlesztők csak becsapják magukat, hogy majd sokkal kevesebbet kell kódolni. Hihetetlenül észnél kell lenni, mert elég egy legyintés, hogy ez így majdnem jó, és oda minden előnye a generált cuccoknak. Ezt a legtöbben nem is látják, mert valamiért nem foglalkoznak a release utáni életciklussal. Ugyanez igaz a DTO-ra is, hogy leszámítva azt az 1%-ot, amikor tényleg kellene, csak felesleges karbantartási köröket, és kockázati tényezőt vezetnek be a projektbe. Az ember hajlamos elsiklani olyan problémák felett, amiket nem lát rögtön, mert kényelmes nem szembesülni vele.
Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére. Nem 1% az, amit kézimunkával kell megoldani, de erről már a múltkor beszéltünk a lazy-eager-dto témában.
Nálunk a legtöbb szívás a GWT-vel a frontend hibái miatt voltak. Még csak nem is a generált kód és a backend közti szakadék miatt. A frontendesek annyira sokat dolgoztak a minimális hibákon, hogy a végeredmény az lett, hogy vagy sikerült megalkudni a megrendelővel, vagy addig hegesztették böngészőnként a dolgot, hogy az összköltsége elszaladt egy bootstrap/foundation alapokra épülő jquery/sencha kliens + SOA backend mellett. Sajnos vagy sem, de eddig mindig ide lyukadtunk ki, akármi is volt a kiindulási alap.
Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére.
Kb. ennyi volt az előnye mindig is
-
floatr
veterán
Jó, a generált kód nyilván nem az elérhető legjobb, viszont megvan az az előnye, hogy a minősége(legyen az bármilyen) állandó.
És ha most maradunk a GWT-nél, akkor ki lehet mondani, hogy sokkal jobb a generált JS kód minősége, mint amilyet bármelyik csak Java-s, de még gyakorlott JS fejlesztő is tudna gyártani "kézzel".
És ne felejtsük el azt sem, ha már a Spring/Hibernate és egyebek szóba kerültek, hogy ezek a generált szarok az esetek 99%-ban megfelelő minőségűek az adott feladathoz. A maradék 1%-ban meg jössz Te és implementálod az ultimate kódot
-
Aethelstone
addikt
Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
Aethelstone
addikt
Bizonyos fokig a compiler is átver. Még az elmúlt évezredben volt egy olyan hardveres problémája az x86-os prociknak, amikor bejött a pipeline, hogy bizonyos kódegyüttállás esetén az egymást követő utasításokat x lépésen belül egyszerűen nem tudta feldolgozni. Ezt a legtöbb C fordító korrigálta úgy, hogy te nem tudtál róla. Ez a pozitív része az átverésnek, ha jól csinálta. Volt azonban olyan C fordító, ami úgy optimalizálta a fordított kódot, hogy éppen belefutott ebbe a pipeline/cache hibába.
Itt viszont egyik nyelvről a másikra generál egy kódot, amit egy framework keresztimplementáció igyekszik elfedni. A dolog már ott sántít, hogy eltérő implementációkról van szó.
A hibernate/JPA által generált SQL-re inkább nem mondok semmit. Nem véletlen, hogy nagyon kevés a jó HQL/JPQL szakember, mint ahogy az sem, hogy a kritikus query-k mind natív SQL-ben készülnek, vagy tárolt eljárásban. Amit meg a proxy-kkal, ASM/CGLIB meg egyéb témával generálnak, az nem ugyanaz a nagyságrend, amivel egy Java-JS fordításnál szembesülsz.
(#7227) Aethelstone Ja hogy a parse-oláshoz beaneket, milyen igaz. Úgy szar ahogy van
)
Kézzel jobbat gyártottam, és ráadásul tudtam, hol kell a sallangot kicsapni.
De mondhatnád a spring boot-ot is, a hibernate entitás/schema generátorát, meg ilyenek. Nem akarom elvinni a témát a nagyzolás irányába, de ezeket ha tehetem kerülöm, mint a pestisest. Még talán a schema generátor elmegy, de azon is sokat kell utólag szöszölni, mire összeáll úgy, ahogy szeretném, mert nem lehet eléggé teletűzdelni metaadatokkal, hogy mindent normálisan megcsináljon. Sajnizom, hogy rossz véleményem van rólaJó, a generált kód nyilván nem az elérhető legjobb, viszont megvan az az előnye, hogy a minősége(legyen az bármilyen) állandó.
És ha most maradunk a GWT-nél, akkor ki lehet mondani, hogy sokkal jobb a generált JS kód minősége, mint amilyet bármelyik csak Java-s, de még gyakorlott JS fejlesztő is tudna gyártani "kézzel".
És ne felejtsük el azt sem, ha már a Spring/Hibernate és egyebek szóba kerültek, hogy ezek a generált szarok az esetek 99%-ban megfelelő minőségűek az adott feladathoz. A maradék 1%-ban meg jössz Te és implementálod az ultimate kódot
-
Aethelstone
addikt
Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
floatr
veterán
Ergó nem a technológia szar, hanem a fejlesztők
Ezzel kezdtem a threadet És most ezzel zárnám is Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
Ezzel altalanossagban nem ertek egyet. Ha nagyon tavolrol nezed, akkor a javac meg kesobb a JVM is kodot general, a legmagasabb (Java) absztrakcios szintrol kezdve vegig a gepi kodig. Az, ha ennek a tetejere meg raksz valamit, alapvetoen nem rontja el a dolgot. Arra nyilvan figyelni kell, hogy az absztrakciok sose tokeletesek, de ez siman lehet elfogadhato kompromisszum. A Hibernate is kodot general, peldaul.
Bizonyos fokig a compiler is átver. Még az elmúlt évezredben volt egy olyan hardveres problémája az x86-os prociknak, amikor bejött a pipeline, hogy bizonyos kódegyüttállás esetén az egymást követő utasításokat x lépésen belül egyszerűen nem tudta feldolgozni. Ezt a legtöbb C fordító korrigálta úgy, hogy te nem tudtál róla. Ez a pozitív része az átverésnek, ha jól csinálta. Volt azonban olyan C fordító, ami úgy optimalizálta a fordított kódot, hogy éppen belefutott ebbe a pipeline/cache hibába.
Itt viszont egyik nyelvről a másikra generál egy kódot, amit egy framework keresztimplementáció igyekszik elfedni. A dolog már ott sántít, hogy eltérő implementációkról van szó.
A hibernate/JPA által generált SQL-re inkább nem mondok semmit. Nem véletlen, hogy nagyon kevés a jó HQL/JPQL szakember, mint ahogy az sem, hogy a kritikus query-k mind natív SQL-ben készülnek, vagy tárolt eljárásban. Amit meg a proxy-kkal, ASM/CGLIB meg egyéb témával generálnak, az nem ugyanaz a nagyságrend, amivel egy Java-JS fordításnál szembesülsz.
(#7227) Aethelstone Ja hogy a parse-oláshoz beaneket, milyen igaz. Úgy szar ahogy van
)
Kézzel jobbat gyártottam, és ráadásul tudtam, hol kell a sallangot kicsapni.
De mondhatnád a spring boot-ot is, a hibernate entitás/schema generátorát, meg ilyenek. Nem akarom elvinni a témát a nagyzolás irányába, de ezeket ha tehetem kerülöm, mint a pestisest. Még talán a schema generátor elmegy, de azon is sokat kell utólag szöszölni, mire összeáll úgy, ahogy szeretném, mert nem lehet eléggé teletűzdelni metaadatokkal, hogy mindent normálisan megcsináljon. Sajnizom, hogy rossz véleményem van róla -
Aethelstone
addikt
Figy, én eddig azt láttam, hogy valaki vagy az egyikhez ért, vagy a másikhoz. Az már fehér holló kategória, aki valamennyire konyít mindkettőhöz, és ez nem csak hazai jelenség. Irtózatosan híg a szakma, és nem biztos hogy csak a képzéssel van a baj (bár a kollégám, aki elég húzós tanfolyamokat tart, erről meg van győződve). A legtöbb gyíkarc meg sem érti, hogy mitől gurul az egész, vagy ha elcsípi, akkor menekül tőle, mert a JS nem elég tudományos. Erre mondom, hogy kliens oldali technológiát, csak arra megfelelő emberekkel szabad gyártani, és ezek az emberek nem feltétlenül kell h backendet is tudjanak gyártani. Ezek a hibrid megoldások olyanok, mint a 4 évszakos gumi.
Vagy használjanak jfx-et, az tudományosabbabb. (bár az is halódik elfelé)
Szerk.: amit generálásképpen említettél, az metaadatokat/leírókat generál, nem kódot.
Ergó nem a technológia szar, hanem a fejlesztők
Ezzel kezdtem a threadet És most ezzel zárnám is -
Aethelstone
addikt
Figy, én eddig azt láttam, hogy valaki vagy az egyikhez ért, vagy a másikhoz. Az már fehér holló kategória, aki valamennyire konyít mindkettőhöz, és ez nem csak hazai jelenség. Irtózatosan híg a szakma, és nem biztos hogy csak a képzéssel van a baj (bár a kollégám, aki elég húzós tanfolyamokat tart, erről meg van győződve). A legtöbb gyíkarc meg sem érti, hogy mitől gurul az egész, vagy ha elcsípi, akkor menekül tőle, mert a JS nem elég tudományos. Erre mondom, hogy kliens oldali technológiát, csak arra megfelelő emberekkel szabad gyártani, és ezek az emberek nem feltétlenül kell h backendet is tudjanak gyártani. Ezek a hibrid megoldások olyanok, mint a 4 évszakos gumi.
Vagy használjanak jfx-et, az tudományosabbabb. (bár az is halódik elfelé)
Szerk.: amit generálásképpen említettél, az metaadatokat/leírókat generál, nem kódot.
-
floatr
veterán
Ez nem igaz. Nincs semmi baj a kódgenerálással. Azzal van baj, ha a fejlesztőnek halvány fingja nincs, hogy mi generálódik. Nem kell pontosan tudni, de nem árt, ha mondjuk azt tudja, hogy JS lesz és böngészőben fog futni.
Engem(és másokat, akik akítvan GWT-znek) érdekes módon nem ver át....elején megtette, de az RTFM sokat tud segíteni. Sok más dolog van ami generál. xsd pl.És különben is, ha valaki nagyon kíváncsi, hogy mi generálódik, meg tudja nézni. Ott van feketén fehéren a JS forrás. Jah, hogy érteni kellene egy picit hozzá? Ez egy ilyen binisz
-
Aethelstone
addikt
Ezért mondom h dead end. Csak olyan frameworknek van értelme, ami nem új kódot generál, egyébként átveri a saját fejlesztőit is, mert kiveszi a kezükből a kontrollt.
Ez nem igaz. Nincs semmi baj a kódgenerálással. Azzal van baj, ha a fejlesztőnek halvány fingja nincs, hogy mi generálódik. Nem kell pontosan tudni, de nem árt, ha mondjuk azt tudja, hogy JS lesz és böngészőben fog futni.
Engem(és másokat, akik akítvan GWT-znek) érdekes módon nem ver át....elején megtette, de az RTFM sokat tud segíteni. Sok más dolog van ami generál. xsd pl.És különben is, ha valaki nagyon kíváncsi, hogy mi generálódik, meg tudja nézni. Ott van feketén fehéren a JS forrás. Jah, hogy érteni kellene egy picit hozzá? Ez egy ilyen binisz
-
Aethelstone
addikt
-
M_AND_Ms
veterán
Kliensen akart pagert.
-
floatr
veterán
Szerintem nem dead end, de ez most nem ide tartozik.
A GWT-vel alapvetően egy baj van, a fejlesztők. Úgy reklámozzák, hogy nulla JS tudással, Java fejlesztői képességek birtokában bárki össze tud vele kókányolni egy webalkalmazást. Aztán jön az egyszeri Java fejlesztő, finga nincs a css-ről, a div-ről meg általában a böngészős normákról és csodálkozik, hogy le akar fetchelni a szerverről 4-5K rekordot és ki akarja csapni a képernyőre....aztán a böngésző lefexik....és sorolhatnám...nem tudják használni. Teljesen nem veszik figyelembe, hogy a vége generált JS kód lesz...sírnak, hogy miért nincs reflection meg ilyesmi...
-
Aethelstone
addikt
-
M_AND_Ms
veterán
Szerintem nem dead end, de ez most nem ide tartozik.
A GWT-vel alapvetően egy baj van, a fejlesztők. Úgy reklámozzák, hogy nulla JS tudással, Java fejlesztői képességek birtokában bárki össze tud vele kókányolni egy webalkalmazást. Aztán jön az egyszeri Java fejlesztő, finga nincs a css-ről, a div-ről meg általában a böngészős normákról és csodálkozik, hogy le akar fetchelni a szerverről 4-5K rekordot és ki akarja csapni a képernyőre....aztán a böngésző lefexik....és sorolhatnám...nem tudják használni. Teljesen nem veszik figyelembe, hogy a vége generált JS kód lesz...sírnak, hogy miért nincs reflection meg ilyesmi...
-
Aethelstone
addikt
Szerintem a GWT-t is hozzáadhatod a dead end kategóriához
Sok technológiával volt már dolgom, de az ügyviteli felhasználásnál, és az újabb fajta webes alkalmazásoknál a SOA-jellegű backend + "natívan" fejlesztett erős kliens volt a leghatékonyabb. Az csak plusz, ha a kliens oldal olyan framework-ökre épít, amivel napok alatt lefejleszted azt, amihez MVC-vel hónapok munkája kellett.
(#7216) Oppenheimer Ha valami beadandó cuccról/szakdolgozatról van szó, akkor én nem erőltetném a finomságokat
Nekem sem tudták értékelni, amikor én agyaltam rajta. Diplomamunkaként egy GIS alapú facility management megvalósíthatósági tanulmányt adtam le, ami még ráadásul az egyetem munkáját is megkönnyítette volna, és egy rakat diákot rá lehetett volna robbantani a témára szervezetten, mire a vizsgabiztos csak annyit kérdezett, hogy mi ez az egész -
floatr
veterán
Az MVC önmagában egy elavult szar szerintem....ahogy írod is, a felesleges oldalletöltések miatt. Nekünk van még pár MVC-s projektünk, de kimerülnek már a default oldal letöltésében. Minden egyéb forgalom ajax/json kombóval megy.
A DTO-s okosságnak ott van egyébként értelme, ahol az entitásból kinyerhető adatok és a struktúrájuk valamiért köszönőviszonyban sincs azzal, amit a kliensre le kell zavarni(láttam már ilyet)...másrészről nekem sok GWT-s projektem volt és ott sokáig a DTO design patternt erőltették. Mostanában nem tudom, hogy miként van...2.4-nél leakadtam..
Szerintem a GWT-t is hozzáadhatod a dead end kategóriához
Sok technológiával volt már dolgom, de az ügyviteli felhasználásnál, és az újabb fajta webes alkalmazásoknál a SOA-jellegű backend + "natívan" fejlesztett erős kliens volt a leghatékonyabb. Az csak plusz, ha a kliens oldal olyan framework-ökre épít, amivel napok alatt lefejleszted azt, amihez MVC-vel hónapok munkája kellett.
(#7216) Oppenheimer Ha valami beadandó cuccról/szakdolgozatról van szó, akkor én nem erőltetném a finomságokat
Nekem sem tudták értékelni, amikor én agyaltam rajta. Diplomamunkaként egy GIS alapú facility management megvalósíthatósági tanulmányt adtam le, ami még ráadásul az egyetem munkáját is megkönnyítette volna, és egy rakat diákot rá lehetett volna robbantani a témára szervezetten, mire a vizsgabiztos csak annyit kérdezett, hogy mi ez az egész -
A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.
Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.
Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.
Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.
-
Aethelstone
addikt
A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.
Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.
Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.
Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.
-
-
Alvás helyett gondolkodtam floatr hozzászólásán. Biztos, hogy JSON serialization-ről beszélt. Ha a kapcsolatokra teszek @JsonIgnore-t, akkor amikor csak alap információk kellenek az entitásokról, jól fog működni parszolás. Amikor pedig egy nagy objektumot küldenék, pl Movie, és benne minden kapcsolódó adattal, akkor ilyen esetekre definiálnék wrapper osztályt, és benne lenne minden szükséges adat egy mezőként.
Pl:
public class MovieWrapper {
private MoviesEntity movie;
private ArrayList<ActorsEntity> actors;
private ArrayList<WritersEntity> writers;
// többi kapcsolat
...
// getterek, setterek
}Ezt az objektumot gyönyörűen meg tudom konstruálni a business logic layerben, amikor még van hibernate sessionöm, és így nincs konverzió, kódduplikáció, csak 1 kis extra karbantartás.
Kérdés: Jackson tudni fogja ezt parszolni? Most nem tudom kipróbálni, mert már aludni akarok, és mobilról írtam.
-
Az alapvető probléma az, hogy két helyen kell ugyanazt karbantartani. Amíg csak néhány entitásról van szó, oké, de amikor elkezd növekedni a számuk, és elkezdenek ezek változni is, akkor születnek újabb bogárkák.
Mert például valaki elfelejtette átvezetni a módosítását a másik osztályba, elfelejtődik, és később jönnek a hibák.
Röviden: a duplikált kód rossz.Ez persze nem jelenti azt, ne lehetnél vele boldog, csak érdemes jobb megoldás után kutatni.
Láttam olyan helyet, ahol ennek a menedzselésére bevezették a kódgenerálást. Ott aztán már durva állapotok vannak, ha az ember ilyesmire kényszerül. Egy xtend leíróban legózhatod össze a java forráskódot töredékekből, ezzel többféle forrást is generálhatsz, amit majd a compiler fordít, stbstb. Így xtend-ben kell egyszer megírni a cuccot és az akár 20 féle DTO-t is kigenerál neked. Vagy amennyit akarsz. Tiszta káosz. Cserébe viszont az xtend nehezebben olvasható. Vagy lehet, hogy csak szokni kell. Szerencsére nem sokáig kellett gyönyörködnöm benne.
Alvás helyett gondolkodtam floatr hozzászólásán. Biztos, hogy JSON serialization-ről beszélt. Ha a kapcsolatokra teszek @JsonIgnore-t, akkor amikor csak alap információk kellenek az entitásokról, jól fog működni parszolás. Amikor pedig egy nagy objektumot küldenék, pl Movie, és benne minden kapcsolódó adattal, akkor ilyen esetekre definiálnék wrapper osztályt, és benne lenne minden szükséges adat egy mezőként.
Pl:
public class MovieWrapper {
private MoviesEntity movie;
private ArrayList<ActorsEntity> actors;
private ArrayList<WritersEntity> writers;
// többi kapcsolat
...
// getterek, setterek
}Ezt az objektumot gyönyörűen meg tudom konstruálni a business logic layerben, amikor még van hibernate sessionöm, és így nincs konverzió, kódduplikáció, csak 1 kis extra karbantartás.
Kérdés: Jackson tudni fogja ezt parszolni? Most nem tudom kipróbálni, mert már aludni akarok, és mobilról írtam.
-
Az alapvető probléma az, hogy két helyen kell ugyanazt karbantartani. Amíg csak néhány entitásról van szó, oké, de amikor elkezd növekedni a számuk, és elkezdenek ezek változni is, akkor születnek újabb bogárkák.
Mert például valaki elfelejtette átvezetni a módosítását a másik osztályba, elfelejtődik, és később jönnek a hibák.
Röviden: a duplikált kód rossz.Ez persze nem jelenti azt, ne lehetnél vele boldog, csak érdemes jobb megoldás után kutatni.
Láttam olyan helyet, ahol ennek a menedzselésére bevezették a kódgenerálást. Ott aztán már durva állapotok vannak, ha az ember ilyesmire kényszerül. Egy xtend leíróban legózhatod össze a java forráskódot töredékekből, ezzel többféle forrást is generálhatsz, amit majd a compiler fordít, stbstb. Így xtend-ben kell egyszer megírni a cuccot és az akár 20 féle DTO-t is kigenerál neked. Vagy amennyit akarsz. Tiszta káosz. Cserébe viszont az xtend nehezebben olvasható. Vagy lehet, hogy csak szokni kell. Szerencsére nem sokáig kellett gyönyörködnöm benne.
-
Az alapvető probléma az, hogy két helyen kell ugyanazt karbantartani. Amíg csak néhány entitásról van szó, oké, de amikor elkezd növekedni a számuk, és elkezdenek ezek változni is, akkor születnek újabb bogárkák.
Mert például valaki elfelejtette átvezetni a módosítását a másik osztályba, elfelejtődik, és később jönnek a hibák.
Röviden: a duplikált kód rossz.Ez persze nem jelenti azt, ne lehetnél vele boldog, csak érdemes jobb megoldás után kutatni.
Láttam olyan helyet, ahol ennek a menedzselésére bevezették a kódgenerálást. Ott aztán már durva állapotok vannak, ha az ember ilyesmire kényszerül. Egy xtend leíróban legózhatod össze a java forráskódot töredékekből, ezzel többféle forrást is generálhatsz, amit majd a compiler fordít, stbstb. Így xtend-ben kell egyszer megírni a cuccot és az akár 20 féle DTO-t is kigenerál neked. Vagy amennyit akarsz. Tiszta káosz. Cserébe viszont az xtend nehezebben olvasható. Vagy lehet, hogy csak szokni kell. Szerencsére nem sokáig kellett gyönyörködnöm benne.
-
Jobban belegondolva a google is szereti halmozni a rest hívásokat. Jó, persze mögötte ott egy bazinagy elosztott rendszer.
Pl. gmail:
Listás nézetben csak az első x db mail látszik (sender, subject és esetleg a body eleje). Nem fogja lehúzni az összes email összes tartalmát. Sőt egy conversationbe belépve sem tölt le mindent, csak az elsőt meg az utolsót. Ha akarod olvasni a többit majd kattintasz és lehúzza azokat is.
Ez soksok apró hívás, mindig csak a legszükségesebbet letöltve. Így fenn tudja tartani a látszatot, hogy ő milyen gyors. Szóval lehet ezt hatékonyan csinálni, csak meg kell találni az egyensúlyt.Megjegyzem, a konvertálgatást csak utolsó mentsvárként javasoltam.
-
Szmeby
tag
Jobban belegondolva a google is szereti halmozni a rest hívásokat. Jó, persze mögötte ott egy bazinagy elosztott rendszer.
Pl. gmail:
Listás nézetben csak az első x db mail látszik (sender, subject és esetleg a body eleje). Nem fogja lehúzni az összes email összes tartalmát. Sőt egy conversationbe belépve sem tölt le mindent, csak az elsőt meg az utolsót. Ha akarod olvasni a többit majd kattintasz és lehúzza azokat is.
Ez soksok apró hívás, mindig csak a legszükségesebbet letöltve. Így fenn tudja tartani a látszatot, hogy ő milyen gyors. Szóval lehet ezt hatékonyan csinálni, csak meg kell találni az egyensúlyt.Megjegyzem, a konvertálgatást csak utolsó mentsvárként javasoltam.
-
Aethelstone
addikt
-
#39560925
törölt tag
Alternatív megoldásként az entitások xstream annotációkkal ellátása jöhet szóba még. Lightweight és köthető entitásra vagy akár DTO-ra, Bean-re vagy akármire
Függően attól, hogy okoz-e hidegrázást a DTO konverzió, mégha automatikus is Már megírtam a DTO konverziót, nagyon szép lett.
Ezt azért elrakom könyvjelzőkbe, hátha kell még. -
Aethelstone
addikt
Alternatív megoldásként az entitások xstream annotációkkal ellátása jöhet szóba még. Lightweight és köthető entitásra vagy akár DTO-ra, Bean-re vagy akármire
Függően attól, hogy okoz-e hidegrázást a DTO konverzió, mégha automatikus is -
A kód olvashatóságát pedig ez például nem rontja.
)
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Forza sorozat (Horizon/Motorsport)
- A fociról könnyedén, egy baráti társaságban
- Szombathely és környéke adok-veszek-beszélgetek
- AMD Navi Radeon™ RX 9xxx sorozat
- Apple MacBook
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Projektor topic
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Villanyszerelés
- Motoros topic
- További aktív témák...
- Macbook Pro 16" A2485 2021 M1 MAX 32/1TB 32 GPU Astro (Dobozos, 16 ciklus 100% akku)
- Apple Watch Series 11 GPS + Cellular 46mm fekete, magyar, 3 év garancia
- GYÖNYÖRŰ MacBook Pro 14" M2 Pro 16 GB - 512 GB GAR ÉS jótállás!
- Intel Core ULTRA 9 285K +32GB 7600MHz Patriot Viper XTREME 5 DDR5 kit! (Bolti ár: kb 600ezer Ft!)
- Lenovo Legion Pro 5 - 16IRX10 - i9 14900HX - RTX 5070 - 32GB - 1TB
- HP EliteBook 840 G6, G5 14" i5, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- GYÖNYÖRŰ iPhone 14 Pro Max 512GB Deep Purple -2 ÉV GARANCIA - Kártyafüggetlen, MS5374, 99% AKKSI
- Lenovo V15 G4 IRU laptop, 15.6", FHD, IPS, lntel Core i5-13420H, 2x8GB, 1TB SSD
- GYÖNYÖRŰ iPhone 15 128GB Pink -2 ÉV GARANCIA - Kártyafüggetlen, MS5469, 90% AKKSI
- Samsung Galaxy S20 Ultra / 12/128GB / Kártyafüggetlen / 12Hó Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest