Archief - ORM, gebruikt jij het?

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.
s

sanzo

Legacy Member
Voor mijn examen van JEE waren we verplicht met JPA te werken, het is effe wennen maar daarna gaat het wel vlot. Ik ben nu iets in php aan het schrijven en ik mis het echt wel (ik weet wel dat er dingen zijn als doctrine enzo, maar dit is nu iets redelijk klein dat ik aan het maken ben)

Werken jullie ermee en wanneer wel/niet? (ORM in het algemeen dus)
C

Cycloon

Legacy Member
Wat is er slecht aan lazy loading? In veel gevallen kan dat net heel voordelig zijn.
M

Moto

Legacy Member
Wat is er slecht aan lazy loading? In veel gevallen kan dat net heel voordelig zijn
Klik om te vergroten...
Ik zou dan toch wel eens willen weten in welke gevallen.

Anyway hier een stukske Nhibernate code van een project dat ik volledig opnieuw aan het maken ben
(code is dus niet van mij ;) )
Code: 
                int dummyForTriggerLazyLoading;

                ICriteria criteria = session.CreateCriteria(typeof(Project))
                    .Add(Expression.Eq("IncludeInBatch", 1))
                    .Add(Expression.Eq("Deleted", 0));
                IList<Project> projects = criteria.List<Project>();

                if (loadCompoundLists)
                    foreach (Project project in projects)
[B]                        // Trigger lazy loading of compounds[/B]
                        dummyForTriggerLazyLoading = project.Compounds.Count;

                return projects;

Persoonlijk vind ik dat dus niet kunnen heh ;)
Magic strings, klungelachtig triggeren van lazy loads, N+1 selects

Performance is 1 van de belangrijkste dingen voor users.
Belangrijkste performance-killer is
teveel trips naar de DB + eerste 3 punten van Fallacies of Distributed Computing - Wikipedia, the free encyclopedia

Veel projecten dus die beginnen met enkel hun eigen aangemaakte test data + lokale DB, lazy loading word dan a volonté gedaan, men hoeft niet na te denken en zal dan dus meestal niet nadenken over de beste fetching strategies.

Voeg dan een miljoen records toe + een database die achter een firewall staat en het is dikke miserie :p
P

Parnakra

Legacy Member
Dat is gewoon een voorbeeld van hoe lazy loading niet te implementeren. Betekent helemaal niet dat het nooit correct kan toegepast worden.
O

Obliv`

Legacy Member
Moto zei:
Ik werk altijd met Welcome to BLToolkit - Business Logic Toolkit for .NET
Is de enigste die ik tot nu toe goed vind, en veel beter dan zaken zoals NHibernate en EF.

Zit bijvoorbeeld geen lazy loading in, ORM's met lazy loading + programmeurs die geen verstand hebben van DB's (de meeste precies) = epic fail
Klik om te vergroten...

Op mijn laatste projecten heb ik gebruik gemaakt van NHibernate en het Entity Framework, waarvan NHibernate zeker en vast mijn voorkeur geniet.

De huidige versie van het EF is ondertussen met de uitgebreidere POCO & Code First support al wel wat bruikbaarder tenopzichte van de vorige versie.

Te veel programmeurs hebben inderdaad weinig verstand van DB's. Wanneer die dan een ORM gebruiken waardoor ze zelf geen SQL meer moeten schrijven, heeft dat vaak een grote catastrofe tot gevolg.

Lazy loading kan wel degelijk nut hebben, als het correct wordt toegepast. Maar met een query op maat, kom je natuurlijk ook al ver.
O

Obliv`

Legacy Member
Moto zei:
Ik zou dan toch wel eens willen weten in welke gevallen.

Anyway hier een stukske Nhibernate code van een project dat ik volledig opnieuw aan het maken ben
(code is dus niet van mij ;) )
Code: 
                int dummyForTriggerLazyLoading;

                ICriteria criteria = session.CreateCriteria(typeof(Project))
                    .Add(Expression.Eq("IncludeInBatch", 1))
                    .Add(Expression.Eq("Deleted", 0));
                IList<Project> projects = criteria.List<Project>();

                if (loadCompoundLists)
                    foreach (Project project in projects)
[B]                        // Trigger lazy loading of compounds[/B]
                        dummyForTriggerLazyLoading = project.Compounds.Count;

                return projects;

Persoonlijk vind ik dat dus niet kunnen heh ;)
Magic strings, klungelachtig triggeren van lazy loads, N+1 selects
Klik om te vergroten...

Dat is echt wel een voorbeeld van hoe het niet moet he.
Ik heb de laatste versie van NHibernate nog niet gebruikt, maar ik veronderstel dat die dingen als Expression.Eq("PropertyName", 0) er wel zullen uit zijn en dat ze nu iets zullen hebben als dit:
Expression.Eq<TEntity>(t => t.Property, 0).
C

Cycloon

Legacy Member
Moto zei:
Ik zou dan toch wel eens willen weten in welke gevallen.
Klik om te vergroten...

Bijvoorbeeld wanneer je een hele boomstructuur van gegevens hebt met duizenden bladeren. In het overzicht wil je enkel bv de 3 bovenste toplagen laten zien, daarna kan de gebruiker dynamisch verder doorklikken in de boom. Zonder lazy loading zou je ORM duizenden knopen en bladeren moeten inladen, terwijl de gebruiker mss hooguit geïnteresseerd is in enkele takken.

Lazy loading is uitgevonden met een reden hoor, niet om elke keer uitgeschakeld te worden :p
M

Moto

Legacy Member
Dat is gewoon een voorbeeld van hoe lazy loading niet te implementeren. Betekent helemaal niet dat het nooit correct kan toegepast worden.
Klik om te vergroten...
Zeg ik ook niet heh, dat het nooit correct kan toegepast worden, alleen kom ik maar weinig nhibernate apps tegen die wel goed zijn
Dat is echt wel een voorbeeld van hoe het niet moet he.
Klik om te vergroten...
Tja, maar ik kom het toch oh zo veel tegen :p
Nuja vroeger toen er nog geen ORM's waren in VB6 kwam ik ook al N+1 selects tegen, crappy programmeurs heh ;)

Zonder lazy loading zou je ORM duizenden knopen en bladeren moeten inladen, terwijl de gebruiker mss hooguit geïnteresseerd is in enkele takken.
Klik om te vergroten...
Euhm? ge kunt zelf bepalen wat ge ophaalt, eager/lazy loading is maar 1 ding van een ORM, het mapping gedeelte waar ge dan via fluent of linq data ophaalt is een ander groot gedeelte.
Trouwens zie ook niet direkt in hoe lazy loading u in dat geval echt gaat helpen ze

Lazy loading is uitgevonden met een reden hoor
Klik om te vergroten...
gemakzucht? :p, Het is niet omdat er een feature bestaat dat ge die ook zomaar moogt gaan gebruiken zonder rekening te houden met uw requirements en zeker zonder kennis van zaken. Nu ondertussen blijf ik natuurlijk wel werkzekerheid hebben met al die mislukte projecten die ik mag overdoen of rechttrekken :p

Ik heb de laatste versie van NHibernate nog niet gebruikt
Klik om te vergroten...
Ik zou zeggen bekijk de volgende keer eens bltoolkit ;)
Dat is tenminste een echte abstractie die u tijd gaat besparen

NHibernate is geen abstractie, misschiens als ge een paar jaar ervaring hebt wel, maar in de meeste gevallen is het constant logging nakijken om te zien als het aantal queries + de queries zelf die uitgevoerd worden aan uw verwachtingen voldoen, dan heb ik liever die zekerheid om het effectief zelf even te doen.
Uiteindelijk is het evenveel werk en ik steek liever iets meer tijd erin op voorhand om iets te maken waarvan ik direkt weet dat het werkt dan dat ik een mapping aanmaak om erna in de logging te checken dat het idd werkt.

De persistence layer is zowiezo iets waar weinig werk in kruipt, maar wat ontzettend belangrijk is voor performance, dus neem ik liever geen risico's (N+1)
E

Emerxill

Legacy Member
Nu ben ik gene .NOT-er (kon't nie laten, sorry :p), maar lazy loading voorkomt toch in de meeste gevallen al N+1 select.
De rest van de gevallen vermijdt ge N+1 select door de juiste fetching-strategie toe te passen (in Hibernate toch).

ORM frameworks zijn imo juist ideaal omdat ge in heel uw applicatie op een OO-manier kunt blijven werken. Ok, ge moet natuurlijk in het achterhoofd houden dat ge met een Relationele DB aant werken zijt, als ge dat vergeet hebt ge rap N+1 selects aan uw broek.

Relationele DB's zijn zo old-fashioned btw OO-DBs FTW! :D
s

sanzo

Legacy Member
Hoe los je dat N+1 probleem op? Gewoon met joins, of zit er meer achter? Want ik kan me moelijk voorstellen dat iets dat zo 'simpel' op te lossen valt zo vaak een probleem vormt.
d

dJeez

Legacy Member
Gebruik ik ORM? Jazeker, voornamelijk voor CRUD operaties. Voor rapportage en in specifieke gevallen, waar een ORM enkel zou tegenwerken, gebruik ik echter steeds directe SQL queries.

Wat PHP betreft kan ik Propel wel smaken, Doctrine beviel mij niet echt.
T

Tyfius

Legacy Member
Moto zei:
Ik werk altijd met Welcome to BLToolkit - Business Logic Toolkit for .NET
Is de enigste die ik tot nu toe goed vind, en veel beter dan zaken zoals NHibernate en EF.

Zit bijvoorbeeld geen lazy loading in, ORM's met lazy loading + programmeurs die geen verstand hebben van DB's (de meeste precies) = epic fail
Klik om te vergroten...
Kan je nog goede sites ivm BLToolkit documentatie aanbevelen? Of (open-source) projecten met concrete voorbeelden.

Ik ben namelijk van plan om voor een project over te schakelen van een custom file format naar een sqlite database formaat. (Verschillende local files wel om het manageable te houden enal.) Voorlopig is mijn plan om - daar ik maar met een tabel of 5 zit en mijn queries redelijk straight forward en simpel zijn een set van centrale set en get functies te voorzien voor die database. Maar het is de eerste keer dat ik zoiets ga aanpakken, en ik weet niet goed wat de beste manier is en of die BLToolkit mij het leven kan vergemakkelijken.
p

passero

Legacy Member
Ik gebruik ADF business components. Enorm handig framework waarmee je datacontrols (JSR227) kan gebruiken en operation bindings in JSF.
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.
Terug
Bovenaan