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
524
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
Veroaste on Suomessa viitisen prosenttiyksikköä liian matala
Veropohjaa on rapautettu käytännössä koko kulunut vuosituhat, jonka vuoksi valtion menoja on jouduttu rahoittamaan velka672395- 661377
Kyläkauppias ajoi kännissä töistä kotiin
Ei edes kallis auto estä humalassa ajamista, vaikka luulisi alkolukko olevan sellaisessa jo vakiovarusteena. https://ww741185EU komissio - EU-elpymisrahoja voidaan käyttää TILAPÄISESTI väärin!
Espanja ohjasi miljardeja euroja – Nyt EU-komissio teki yllättävän paljastuksen Skandaaliksi noussut Espanjan EU-rahoje41107- 79835
Kiitos upeasta palvelusta kukkamyyjä
Kiitos sinulle upea kaunis kukkamyyjä Kuhmon torilla 🌹 Upea iloinen asenteesi ja kaunis hymysi pelasti päiväni ❤️ Jäi19780- 43678
Ratikka Turkuun
Ei hyvä. Ja syy on siinä , kukaan ei osaa suunnitella oikeaa reittiä. Pitää huomioide, kiskoja sijaintia ei voi muutta82660Miehet trikoissaan
On se kauhian näkköistä, kun miehet tiukossa trikkoissa juoksentelloo ja mulukku paestaa trikkoijjen läpi. Kahtokkee pe24638- 30636