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
510
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
Porvarimediat paniikissa demareiden huiman kannatuksen vuoksi
Piti sitten keksiä "nimettömiin lähteisiin" perustuen taas joku satu. Ovat kyllä noloja, ja unohtivat sen, että vaalit986428KATASTROFI - Tytti Tuppurainen itse yksi pahimmista kiusaajista!!!
STT:n lähteiden mukaan SDP:n eduskuntaryhmän puheenjohtaja Tytti Tuppurainen on käyttäytynyt toistuvasti epäasiallisesti3605974Mikä siinä on ettei persuille leikkaukset käy?
On esitetty leikkauksia mm. haitallisiin maataloustukiin, kuin myös muihin yritystukiin. Säästöjä saataisiin lisäksi lei602893Lääppijä Lindtman jäi kiinni itse teosta
Lindtman kyselemättä ja epäasiallisesti koskettelee viestintäpäällikköä. https://www.is.fi/politiikka/art-20000117808521072348Juuri nyt! Tytti Tuppurainen on käyttäytynyt toistuvasti epäasiallisesti
Ai että mä nautin, Tytti erot vireille! "Käytös on kohdistunut avustajia ja toisia kansanedustajia kohtaan, uutisoi STT1072018- 1251774
Puolen vuoden koeaika
Voisi toimia meillä. Ensin pitäis selvittää "vaatimukset" puolin ja toisin, ennen kuin mitään aloittaa. Ja matalalla pro191653Tytti Tuppurainen nöyryyttää avustajiaan
Tytti Tuppurainen nöyryyttää SDP:n eduskuntaryhmän kokouksissa sekä avustajia että kansanedustajia. Hän nolaa ihmisiä ju1811320- 731217
Huomaatteko Demari Tytti ei esitä pahoitteluitaan
Samanlainen ilmeisesti kuin Marin eli Uhriutuu no he ovat Demareita ja muiden yläpuolella siis omasta mielestään331158