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?
Vastaukset 5
- 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
Herkkyydestä
Toisessa ketjussa toivottiin keskustelua herkkyydestä. Aloitan omalla näkemykselläni. Mielestäni herkät ihmiset ovat l285967Arvaako kukaan?
"Humalojalla metalliromun keräyspaikalla on kulkenut pitkin kevättä ja kesää joku henkilö, joka on vienyt sieltä kymmeni52754- 67681
Tuntuu pahalta meidän molempien puolesta
Anteeksi, että olen tällainen pelkuri. En vaan usko rakkauteen enää miehen ja naisen välillä omalla kohdalla. Tiedän, et35604- 49586
- 52574
Olen kiinnostunut sinusta, en seksistä
Vihjailuja toiseen suuntaan on tullut niin paljon, että asia on korjattava. En näe sinua esineenä, vaan hienona persoona33526- 34487
- 48477
- 40475