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
476
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
Riitta-Liisa ja Toni Roponen: Ero! Riitta-Liisa Roponen kertoo asiasta Instagramissa.
Riitta-Liisa ja Toni Roponen eroavat. Riitta-Liisa Roponen kertoo asiasta Instagramissa. – Talvi on ollut elämäni synk863567Sinä vain tulit elämääni
Ja joku tarkoitus sillä on ollut. Näyttämään mitä olen ja kuinka arvokas voisin olla. Se muutti ja käänsi elämäni suunna921919Tiesitkö mies
Kuinka paljon mulla oli tunteita sua kohtaan? Jos et tiennyt,olisiko tietäminen vaikuttanut tapahtumiin? Ihmettelen kyll871743- 1441601
Millaisia ajatuksia on kaivatusta ja tilanteestanne tänään?
Kerro omista mietteistäsi tai lähetä terveisiä. Ehkä hän lukee ja lähettää sinulle takaisin omia mietteitään.651468- 1621453
Mies, mitä minun pitäisi tehdä
Niin, mitä naisen siis pitäisi tehdä, että lähestyisit ja tekisit aloitteen? Mikä on riittävä kiinnostuksen osoitus juur961406Toivottavasti et mussukka elättele toiveita meikäläisen suhteen
Tiedän mitä olet touhunnut joten aivan turha haaveilla mistään enää 👍1671371Jos siis saamme
Sen keskusteluyhteyden niin olisitko jo sinäkin rehellinen ❤️🙏 ne jää meidän välisiksi kaikki. Tarvitsemme toisiamme, j1001314- 861267