Archief - Hibernate should be to programmers what cake mixes are to bakers
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Moto
Legacy Member
dus dat is de enige optie die gij kent nhibernate of sql spaghetti??
.
Dus met de cloud => bandwith = finite, latency is zero, ???
Met de cloud gaat ongeoptimaliseerd data-verkeer ook trager + dan nog eens meer geld kosten
Nee, nhibernate zorgt zeker en vast niet voor die dingen, orm = leaky abstraction = slechtere aanpasbaarheid + onderhoudbaarheid
nogal flauw? het is wat ik telkens zie, al de developers die ik persoonlijk ben tegengekomen en waarvan ik de programmas zelf gezien heb, zijn totaal niet bezig met hun eindgebruiker
nHibernate word telkens gekozen om maar rap rap van de persistence af te zijn en als het dan allemaal trager is who cares of zo als 1 van die mannen zei "Och, dat is wel traag maar ik moet die applicatie toch niet gaan gebruiken"
Of zoals een andere nhibernate developer zei op men opmerking dat een veel gebruikt schermke openen te traag was.
"Ja ok 5 minuten dat duurt wel lang voor dat scherm te openen maar als ze het ene 2 keer openen is dat gecached en duurt dat MAAR 10 seconden"
Cycloon
Legacy Member
NeverwinterX zei:
Het is niet omdat enkele bedrijven het promoten vanuit commercieel oogpunt dat het plots een goede zaak is.
Mocht zelf een grote groep gebruikers dit ooit echt gaan gebruiken dan nog betekent het niet dat het technologisch gezien de beste oplossing is. Er zijn genoeg voorbeelden te vinden van falende technologie die tegen beter weten in toch gebruikt blijft worden.
NeverwinterX
Legacy Member
Moto zei:
Nee je kan ook netjes je SQL schrijven, maar het blijft een plak SQL. Een annotation leest en is beter te begrijpen dan een plak SQL.
Nee dat heb ik niet gezegd. Maar die problemen zijn niet onoverkomelijk. Net zoals bepaalde problemen met Hibernate en consoorten nu niet onoverkomelijk zijn.
Als je de structuur van je database wilt veranderen of je wilt een andere database gebruiken: een hoop SQL code aanpassen of enkele annotations, hm wat zou het gemakkelijkste zijn? Vreemd dat je blijft beweren dat dat bij SQL makkelijker is, mss moet je maar eens wat opzoekingswerk verrichen, informatie genoeg.
Nog meer flauwe generalisering van developers en kansloze extrapolatie van enkele eigen ervaringen en anekdotes.
Cycloon zei:
Het is erg in bij developers om je te verzetten tegen elke nieuwe technologie: of het nu personal computers (vs mainframe), objectgericht programmeren (vs procedural), hibernate (vs sql) of cloud computing (vs waarom is hier eigenlijk geen verzamelnaam voor, desktop/local/earth computing
) is. Elke keer hetzelfde liedje. Mij niet gelaten hoor, maar het komt er toch of jij nu denkt dat het niets is en allemaal een commerciele samenzwering van bedrijven is of niet.Moto
Legacy Member
Heb geen regel SQL in mijn programma, enkel een paar SP's voor zware batch-stuff
De problemen zijn niet onoverkomelijk maar de learning curve + ervaring nodig om die problemen op voorhand te ontwijken, maakt het niet de moeite waard.
Zeker niet als het later onderhouden moet worden door iemand zonder die ervaring.
Flauw? dus laten we duidelijk zijn, Gij maakt uw applicaties met
Hibernate en gij vind de performance van uw applicatie WEL belangrijk?Om maar op de cake-mix terug te komen, als gij ne Cake moet maken, maakt gij dan op de snelste manier een cake zonder naar de kwaliteit te kijken, of doet ge effectief moeite om iets lekkers te bakken?
nieuwe technologie moet 2 dingen doen
1)Mij het als developer makkelijker maken om GOEDE dingen op te leveren
2)De User Experience van de user verbeteren
Als een technologie enkel 1 of 2 of allebei doet -> perfect
Als een technologie enkel 1 doet maar slechter is voor 2 -> fuck it
Veel developers die enkel naar punt 1 kijken
Cycloon
Legacy Member
NeverwinterX zei:Het is erg in bij developers om je te verzetten tegen elke nieuwe technologie: of het nu personal computers (vs mainframe), objectgericht programmeren (vs procedural), hibernate (vs sql) of cloud computing (vs waarom is hier eigenlijk geen verzamelnaam voor, desktop/local/earth computing
Het is ook erg in bij mensen om blindelings in platte commercie te lopen
En of cloud computing er komt, daar ben ik allesbehalve zeker van. Of ORM ooit gemeengoed zal zijn? Ik betwijfel dat ook ten sterkste. Relationele databanken zullen eerder verdwijnen ipv dat ORM zal doorbreken.
NeverwinterX
Legacy Member
Moto zei:Heb geen regel SQL in mijn programma, enkel een paar SP's voor zware batch-stuff
De problemen zijn niet onoverkomelijk maar de learning curve + ervaring nodig om die problemen op voorhand te ontwijken, maakt het niet de moeite waard.
Zeker niet als het later onderhouden moet worden door iemand zonder die ervaring.
Flauw? dus laten we duidelijk zijn, Gij maakt uw applicaties met
Om maar op de cake-mix terug te komen, als gij ne Cake moet maken, maakt gij dan op de snelste manier een cake zonder naar de kwaliteit te kijken, of doet ge effectief moeite om iets lekkers te bakken?
nieuwe technologie moet 2 dingen doen
1)Mij het als developer makkelijker maken om GOEDE dingen op te leveren
2)De User Experience van de user verbeteren
Als een technologie enkel 1 of 2 of allebei doet -> perfect
Als een technologie enkel 1 doet maar slechter is voor 2 -> fuck it
Veel developers die enkel naar punt 1 kijken
Of uw SQL nu in de code staat, in stored procedures, in uw database of het steekt in een gezipte rar met daarin een xml file met daarin de sql op een ftp server op mars, mij maakt het niet uit, het blijft SQL. Tenzij je een concurrent van Hibernate gebruikt of je eigen ontwikkelde systeem, maar dan bewijs je eerder het punt dat ik maak
Nou ja dat wordt dan een welles-nietes want mij lijkt de learning curve en de ervaring nodig voor het onderhouden van Hibernate vs SQL een pak kleiner. En ik herhaal dat je daar wel wat informatie over terugvindt
Ik kies per applicatie afhankelijk van de eisen wat nodig is he.
Je lijkt een beetje een beeld te hebben dat Hibernate garant staat voor significante vertragingen. Dat is niet zo.
Cycloon zei:Het is ook erg in bij mensen om blindelings in platte commercie te lopen
En of cloud computing er komt, daar ben ik allesbehalve zeker van. Of ORM ooit gemeengoed zal zijn? Ik betwijfel dat ook ten sterkste. Relationele databanken zullen eerder verdwijnen ipv dat ORM zal doorbreken.
Dan heb ik belangrijk nieuws voor u: afhankelijk van uw definitie van 'gemeengoed' zijn ORM en cloud computing al gemeengoed of op zijn minst zodanig ingeburgerd dat je het vaak zal tegenkomen.
Cycloon
Legacy Member
NeverwinterX zei:
Gemeengoed is meer dan het hier en daar eens tegenkomen. Gemeengoed is voor mij wanneer het vanzelfsprekend is om voor die zaken te kiezen. Cloud computing zit daar zeker nog niet, hier en daar zijn wat grote bedrijven op de kar gesprongen, maar middelgrote bedrijven en particulieren zullen niet zo snel over zijn. ORM zit een beetje in hetzelfde verhaal. Hier en daar zie je dat wel opduiken, maar het is niet zo dat er bv. even makkelijk overwogen wordt om ORM te gebruiken in tegenstelling tot bv. object georiënteerd programmeren.
Manjak
Legacy Member
Even schuin gelezen. Wij combineren Entity framework met stored procedures. Wanneer het over zware queries gaat giet ik het in een stored, anders ff een lichte LINQ query. Vind het best handig hoor.
Origineel: Performance weegt momenteel niet echt op tegen tijdswinst. Als die er al is.
Edit: Een korte test wees weinig snelheid verschil uit. Daarnaast merk ik geen performance issue, dus ga ik ook niet aan premature optimization doen.
Voordelen: minder typo's, geen sqlmanager classes, gemakkelijk databinden, .. de eerste die in me opkomen. Misschien hebben we alleen de voordelen omdat het nogal oppervlakkig is. Maar op vlak van rapid development doet het toch zijn werk.
Origineel: Performance weegt momenteel niet echt op tegen tijdswinst. Als die er al is.
Edit: Een korte test wees weinig snelheid verschil uit. Daarnaast merk ik geen performance issue, dus ga ik ook niet aan premature optimization doen.
Voordelen: minder typo's, geen sqlmanager classes, gemakkelijk databinden, .. de eerste die in me opkomen. Misschien hebben we alleen de voordelen omdat het nogal oppervlakkig is. Maar op vlak van rapid development doet het toch zijn werk.
dJeez
Legacy Member
Dat is dus duidelijk wat jou (en anderen) doet verschillen van Moto (en anderen). De laatsten schieten bij voorbaat al op iets als zijnde slecht zonder de relevante use case te kennen (ok, dit kon iets genuanceerder, maar dat is alvast wat ik meen te mogen besluiten uit het fervente anti-Hibernate - nu ja NHibernate, dat voor zover ik weet een flauw afkooksel is - betoog). Zoals ik al eerder zei : fine-tuning kan nog steeds achteraf als er zich effectief problemen zouden stellen, ook met Hibernate. Je kan er zelfs *gasp* SQL queries voor gebruiken.Manjak zei:
Om het bij een boutade te houden : "premature optimization is the root of all evil". Wat uiteraard niet wil zeggen dat je je niks van de performantie van je code zou moeten aantrekken, maar overdreven fetisjisme is niet bepaald constructief (laat staan productief). Gebruik de juiste tool voor het probleem dat voorligt, in het ene geval is dat Hibernate, in het andere is dat iets anders.
Ach ja, en dat is uiteraard de fout van Hibernate en niet van de ontwikkelaar in kwestie... Alsof die er ineens een totaal andere visie op zou krijgen indien je hem SQL (of eigenlijk eender wat) laat schrijven.Moto zei:
Want je kan uiteraard geen oog hebben voor kwaliteit als je Hibernate (of een andere lib) gebruikt. Man man man, hoe kortzichtig kan je zijn... Het ene sluit het andere niet uit : Thai food is fastfood by nature, en lekker ook.Moto zei:Flauw? dus laten we duidelijk zijn, Gij maakt uw applicaties met
Om maar op de cake-mix terug te komen, als gij ne Cake moet maken, maakt gij dan op de snelste manier een cake zonder naar de kwaliteit te kijken, of doet ge effectief moeite om iets lekkers te bakken?
Manjak
Legacy Member
Neen, ik bedoel dat het er van afhangt.
Mijn intiele data ophaling zal bijna altijd een sproc zijn. Zeker wanneer het over een grote hoeveelheid data gaat. Maar als ik bvb uit het resultaat details nodig heb gebruik ik hiervoor LINQ en ga ik mijn stored procedure niet aanpassen. Als ik bvb weet dat ik een kleine hoeveelheid data aanspreek, die niet veel zal groeien, zal ik ook eerder grijpen naar LINQ. Is dit bad practice? Zeg het mij maar, ik zou zowel argumenten voor als tegen kunnen vinden.
Nu moet ik wel eerlijk zijn: Soms zou ik op het directe resultaat van een gemapte stored een linq query durven plaatsen. Als ik me niet vergis gaat het entity framework dan eerst deze 2 queries samenvoegen vooraleer iets uit te voeren. Hier heeft de cakemevrouw gelijk dat ik op dat moment niet exact weet wat er onder de motorkap aan het gebeuren is.
Van de cakelady zou ik dan leren: Eerst iets doen met de query, zodat ik zeker weet dat het is uitgevoerd, en dan pas details ophalen.
Ik denk dat er eerder al aangehaald is dat het gemakkelijk is om een hele technologie af te schieten. En dat de waarheid ergens in het midden zal liggen. Vind het in elk geval een interessante discussie aangezien ik momenteel volledig aan het inzetten ben op ORM.
Doet me ook denken aan andere discussies waar ze zeggen 'De STL is slecht' of 'C#, dat doet vanalle imperformante dingen'
Mijn intiele data ophaling zal bijna altijd een sproc zijn. Zeker wanneer het over een grote hoeveelheid data gaat. Maar als ik bvb uit het resultaat details nodig heb gebruik ik hiervoor LINQ en ga ik mijn stored procedure niet aanpassen. Als ik bvb weet dat ik een kleine hoeveelheid data aanspreek, die niet veel zal groeien, zal ik ook eerder grijpen naar LINQ. Is dit bad practice? Zeg het mij maar, ik zou zowel argumenten voor als tegen kunnen vinden.
Nu moet ik wel eerlijk zijn: Soms zou ik op het directe resultaat van een gemapte stored een linq query durven plaatsen. Als ik me niet vergis gaat het entity framework dan eerst deze 2 queries samenvoegen vooraleer iets uit te voeren. Hier heeft de cakemevrouw gelijk dat ik op dat moment niet exact weet wat er onder de motorkap aan het gebeuren is.
Van de cakelady zou ik dan leren: Eerst iets doen met de query, zodat ik zeker weet dat het is uitgevoerd, en dan pas details ophalen.
Ik denk dat er eerder al aangehaald is dat het gemakkelijk is om een hele technologie af te schieten. En dat de waarheid ergens in het midden zal liggen. Vind het in elk geval een interessante discussie aangezien ik momenteel volledig aan het inzetten ben op ORM.
Doet me ook denken aan andere discussies waar ze zeggen 'De STL is slecht' of 'C#, dat doet vanalle imperformante dingen'
passero
Legacy Member
Cycloon zei:Het is ook erg in bij mensen om blindelings in platte commercie te lopen
En of cloud computing er komt, daar ben ik allesbehalve zeker van. Of ORM ooit gemeengoed zal zijn? Ik betwijfel dat ook ten sterkste. Relationele databanken zullen eerder verdwijnen ipv dat ORM zal doorbreken.
Even een vraagje, in welke sector werk jij en hoe groot zijn uw projecten?
Cloud is er! In Belgie is het misschien nog niet aan het opkomen (zoals zoveel dingen) maar het is er. Ik werk in London en hier wordt bijna alles op de cloud gedaan.
Alle projecten die we bij de klanten doen worden op de cloud gehost en we zijn niet de enige...
Kijk naar bedrijven zoals Oracle en IBM. Die investeren massa's in de cloud en ik denk dat die wel weten wat er komt
Wat betreft de discussie... Ik denk dat ORM iets goeds is MAAR de developer moet er verstand van hebben en op een correcte manier gebruiken.
Een van mijn vorige projecten was een project in EJB (eigenlijk gebruikten die enkel eclipseLink) om ORM te doen. Niemand had daar veel verstand van. Ik heb daar ook niet veel verstand van. Mijn kennis zit op een ander framework dus ik zocht wat info op, keek hoe de anderen de implementatie deden en dat was het.
Resultaat... Applicatie was gigantisch traag en toen we gingen uitzoeken waarom werd het ons duidelijk... 1 schermke (met niet zoveel records) genereerde duizenden queries.
De applicatie was gemakkelijk te onderhouden want we gebruiken annotaties, dat klopt maar snelheid...
Het heeft ons dan redelijk wat tijd gekost om de applicatie deftig te doen draaien en dan nog genereerde het framework veel te veel queries.
Voor hetzelfde project zijn we dan begonnen in een andere technologie (ADF business components van Oracle) wat ook een ORM tool is maar totaal niet te vergelijken met hibernate of EJB maar het is hetzelfde princiepe. Die technologie beheers ik wel in tegenstelling tot EJB en hibernate. Resultaat, die applicatie draait tenminste deftig.
Ik ben er van overtuigd dat hibernate ook een goeie technologie is maar je moet ze kunnen gebruiken...
blackrabbit
Legacy Member
'Cloud computing' is toch echt wel een buzz-woord hoor.passero zei:
Wat bedoel je met 'projecten worden op de cloud gehost'?
SVN (voor code) en een webserver (voor project documenten) zijn niet nieuw, maar kan je zeggen dat het hier over 'de cloud' gaat? Is wat mij betreft gewoon online storage.
passero
Legacy Member
blackrabbit zei:
Ik bedoel niet SVN en documenten maar de echte apps.
Het gaat er hem om om gemakkelijk extra servers te hosten en te klonen.
We hebben images klaar staan met verschillende suites geinstalleerd. Komt er een nieuw project dan moeten we enkel die image klonen, deployen en hupla.
Nuja, op zich iets wat al langer bestond maar dat is zo met veel dingen. Ze geven er een nieuwe term aan en plots is het modern en nieuw.
Maar het is wel iets wat meer en meer opkomt en heel gemakkelijk is.
Klanten vragen een bepaalde service (suite van apps), wij klonen een image en doen een minimum aan config en kunnen dan direct beginnen ontwikkelen zonder veel tijd te moeten steken in config van het systeem.
Wanneer er dan extra resources nodig zijn, kan er gemakkelijk een nieuwe server gehost worden. Het is dus ideaal voor scalabilitu zoals Parnakra al aangehaald heeft.
Als ik kijk met de technologie waar ik mee werk, dan is die perfect ontwikkeld om gehost te worden in een cloud waar server heel gemakkelijk toegevoegd kunnen worden afhankelijk van de resource noden.
Moto
Legacy Member
Ik gebruik iets met een veel lager abstractie-niveau dan Hibernate/EF, en dus ook veel lagere learning curve. en veel minder problemen want ik weet precies hoe mijn abstractie werkt
Nogmaal
Hibernate is leaky abstraction, wat wilt zeggen dat voor een echte applicatie er toch stukken in Sql/Stored Procedures gestoken moet worden + zoals in de presentatie als ge met een relationele DB werkt doet ge zowiezo tijdens development er SQL queries op, dus neeHibernate gebruiken of EF gebruiken puur uit gemakzucht + zonder te weten wat de abstractie onderling doet + u ook niets aantrekken van eventuele performance voor de eindgebruiker is NIET GOED BEZIG.Ge moet niet 1 ding daaruit pikken (gebruik van nhibernate) en u aangevallen voelen
Uiteindelijk maakt het niet echt uit als ge zo ene rommel gebruikt als uw eindgebruiker tevreden is, is nog altijd het belangrijkste
Dus dJeez ik schiet dus vooral op de combinatie niet op enkel
hibernate anyway de huidige trend is gewoon triest
Succes is geen garantie voor tevredenheid - Datanews.be
Zoals al eerder gezegd, niet de fout van hibernate, wel van de ontwikkelaar die het voor de verkeerde dingen + op de verkeerde manier + voor de verkeerde reden gebruiken.
Moesten die personen zelf de SQL schrijven zou de kans op success al veel groter zijn
(bv minder N+1 Selects door lazy loading ed, meer nadenken over een persistence strategy)
Cycloon
Legacy Member
passero zei:
Jouw definitie van cloud computing is dan totaal anders de mijne. Wat server images clonen en deployen bestaat al jaren. Cloud computing is voor mij eerder zowat alle diensten vanop een centrale server uitvoeren, ook de applicatie zelf. Dus niet ergens op je fysieke pc een app draaien die naar een server connecteert.
Maar we gaan serieus
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.