Ei ole vuotta jolloin ei tulisi uutta käänteentekevää ohjelmoinnin täysin mullistavaa sovelluskehikkoa (framework)... Open Source menee tässä metsään... Useimmissa kehikoissa oppimiskynnys (niin että OIKEASTI osaa käyttää hyödykseen niitä) on aika korkea ja abstraktio taso nousee. Esimerkiksi Hibernate (ajatuksena hyvä) eikö tämän pääasia ole tehdä relaationkanta ns. "näkymättömäksi" sovelluskehittäjälle? Ainoa vaan että jos ei ole IDE:ä mikä generoi nämä O/R mappaukset niin väitän että XML-kuvausten väsäämisessä menee enemmän aikaa kuin Statement:tien kirjoittaminen?
Sovelluskehikot Suolesta
_Kyllästynyt
5
502
Vastaukset
- fidel1
Tai sitten sä et vain osaa..
Hibernaten mapping-tiedostojen tekeminen on hyvinkin suoraviivaista, jos tietokanta ja sovellus on suunniteltu hyvin. Ja jos nyt ei millään onnistu kuvauksia itse saamaan aikaan, niin hibernatesta löytyy työkaluja, jotka pulauttavat automaattisesti kannan scheman mukaiset tiedostot..
Mutta niin se vaan on, maailma on täynnä monimutkaisia ongelmia, joihin ei välttämättä voi kovin yksinkertaisia ratkaisuja keksiä..- Tympääntynyt
"Monimutkaisia ongelmia" ??? TÄMÄ kun nyt ei satu olemaan niitä. Maailma on täynnä yksinkertaisia asioita joita monimutkaistetaan liikaa.
Perustavan laatuinen ongelma tässä on se että relaatio- ja oliomalli eivät mene yksi yhteen. Kysymys ei olekaan siitä että et saisi luotua olioita tauluista, mutta suurempi ongelma on se että on paljon vaikeampaa tehdä monimutkaisia kyselyjä tässä mallissa. Eikö olisi helpompaa kirjoittaa SQL jonka upottaa statementtiin ja käsittelee sitten saamansa datan haluamallaan tavalla? Nyt joudut miettimään miten juuri tässä sovelluskehyksessä asian voisi hoitaa, ja tämän jälkeen menet projektiin jossa joku on juuri päättänyt käyttää Toplink:iä Hibernaten sijaan. Jos olet koodari ja esim. projektipäällikkö tämän päättää niin se on voi voi... Silloin otat Toplink oppaan käteen ja alat miettiä miten monimutkaisia kyselyjä tehdään tässä.
On todella helppoa jos on muutama taulu ja yksinkertainen käsitemaailma. Silloin sovelluskehys toimii vain välittäjänä joka tekee DML-operaatiot kantaan. Entä jos tauluja on satoja ja näistä tulee yhdistää yksi kysely jonka tulos pitää näyttää yhdellä näytöllä? Ja tällä näytöllä pitää pystyä muuttamaan niitä tietoja? Miten valutat sen yksinkertaisesti esim. Hibernaten läpi kantaan? (En siis tiedä... Jos se on helppoa niin hyvä niin...) - fidel1
Tympääntynyt kirjoitti:
"Monimutkaisia ongelmia" ??? TÄMÄ kun nyt ei satu olemaan niitä. Maailma on täynnä yksinkertaisia asioita joita monimutkaistetaan liikaa.
Perustavan laatuinen ongelma tässä on se että relaatio- ja oliomalli eivät mene yksi yhteen. Kysymys ei olekaan siitä että et saisi luotua olioita tauluista, mutta suurempi ongelma on se että on paljon vaikeampaa tehdä monimutkaisia kyselyjä tässä mallissa. Eikö olisi helpompaa kirjoittaa SQL jonka upottaa statementtiin ja käsittelee sitten saamansa datan haluamallaan tavalla? Nyt joudut miettimään miten juuri tässä sovelluskehyksessä asian voisi hoitaa, ja tämän jälkeen menet projektiin jossa joku on juuri päättänyt käyttää Toplink:iä Hibernaten sijaan. Jos olet koodari ja esim. projektipäällikkö tämän päättää niin se on voi voi... Silloin otat Toplink oppaan käteen ja alat miettiä miten monimutkaisia kyselyjä tehdään tässä.
On todella helppoa jos on muutama taulu ja yksinkertainen käsitemaailma. Silloin sovelluskehys toimii vain välittäjänä joka tekee DML-operaatiot kantaan. Entä jos tauluja on satoja ja näistä tulee yhdistää yksi kysely jonka tulos pitää näyttää yhdellä näytöllä? Ja tällä näytöllä pitää pystyä muuttamaan niitä tietoja? Miten valutat sen yksinkertaisesti esim. Hibernaten läpi kantaan? (En siis tiedä... Jos se on helppoa niin hyvä niin...)> On todella helppoa jos on muutama taulu ja
> yksinkertainen käsitemaailma. Silloin
> sovelluskehys toimii vain välittäjänä joka tekee
> DML-operaatiot kantaan. Entä jos tauluja on satoja
> ja näistä tulee yhdistää yksi kysely jonka tulos
> pitää näyttää yhdellä näytöllä? Ja tällä näytöllä
> pitää pystyä muuttamaan niitä tietoja? Miten
> valutat sen yksinkertaisesti esim. Hibernaten läpi
> kantaan? (En siis tiedä... Jos se on helppoa niin
> hyvä niin...)
no eihän se hibernate käyttäminen nyt estä samaan aikaan käyttämästä suoraan sql:ää. Tai jos paha projektipäällikkö vaatii, niin hibernaten läpi voi tietoja hakea sql:llä, hql:llä (hibernate query language) tai tekemällä kriteerihakuja.
Tietenkään Hibernate ei ole ratkaisu kaikkeen. Eikä mikään muukaan kehys/kieli/tekniikka. Mutta jos se perustellusti parhaiten soveltuu ratkaisemaan käsillä olevan ongelman, niin silloin sitä kannattaa opetella käyttämään. Ei lisäoppi ole koskaan ketään vahingoittanut, ja jos joku vielä maksaa palkkaakin uuden opettelusta, niin mikäs ongelma siinä sitten on? - joxxx
Tympääntynyt kirjoitti:
"Monimutkaisia ongelmia" ??? TÄMÄ kun nyt ei satu olemaan niitä. Maailma on täynnä yksinkertaisia asioita joita monimutkaistetaan liikaa.
Perustavan laatuinen ongelma tässä on se että relaatio- ja oliomalli eivät mene yksi yhteen. Kysymys ei olekaan siitä että et saisi luotua olioita tauluista, mutta suurempi ongelma on se että on paljon vaikeampaa tehdä monimutkaisia kyselyjä tässä mallissa. Eikö olisi helpompaa kirjoittaa SQL jonka upottaa statementtiin ja käsittelee sitten saamansa datan haluamallaan tavalla? Nyt joudut miettimään miten juuri tässä sovelluskehyksessä asian voisi hoitaa, ja tämän jälkeen menet projektiin jossa joku on juuri päättänyt käyttää Toplink:iä Hibernaten sijaan. Jos olet koodari ja esim. projektipäällikkö tämän päättää niin se on voi voi... Silloin otat Toplink oppaan käteen ja alat miettiä miten monimutkaisia kyselyjä tehdään tässä.
On todella helppoa jos on muutama taulu ja yksinkertainen käsitemaailma. Silloin sovelluskehys toimii vain välittäjänä joka tekee DML-operaatiot kantaan. Entä jos tauluja on satoja ja näistä tulee yhdistää yksi kysely jonka tulos pitää näyttää yhdellä näytöllä? Ja tällä näytöllä pitää pystyä muuttamaan niitä tietoja? Miten valutat sen yksinkertaisesti esim. Hibernaten läpi kantaan? (En siis tiedä... Jos se on helppoa niin hyvä niin...)Tämän takia Hibernatea (ja vastaavia) suositellaankin käytettäviksi ainoastaan jos tietokanta voidaan suunnitella "puhtaalta pöydältä".
Joku iBatis sopii paremmin tilanteeseen, jossa kannan rakenteeseen ei enää voi vaikuttaa.
- Handyman
Hibernate on huono esimerkki tarkoitukseesi. XDoclet on sitä varten, ettei mappauksia tarvitse tehdä käsin edes vanhoilla java-versioilla.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Vain vasemmistolaiset rakennemuutokset pelastavat Suomen
Kansaa on ankeutettu viimeiset 30+ vuotta porvarillisella minäminä-talouspolitiikalla, jossa tavalliselta kansalta on ot403460Persut huutaa taas: "kato! muslimi!"
Persut on lyhyessä ajassa ajaneet läpi kaksi työntekijöiden oikeuksien heikennystä, joita se on aiemmin vastustanut. Pe132848- 282514
- 421977
- 161861
- 471824
- 531799
- 551533
KL: Mari Hynynen avoimena - Jouni-rakkaan ja Joel-pojan välit ovat nämä!
Mari Hynynen (ent. Perankoski) on naimisissa Jouni Hynysen kanssa. Marilla on edellisestä liitosta yksi lapsi, Joel Vola101488Missikohu edustaa nykyajan monimuotoisuutta
Puolesta vai vastaan, saako esittää pilkkaavasti jonkun toisen ihmisen syntyperäisiä ominaisuuksia? Kadulla vastaan tule2651183