[ALG/C#] Opzet datalayer

Pagina: 1
Acties:
  • 671 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik blijf mij altijd een beetje achter de oren krabben mbt. het opzetten van dit soort dingen, dus ik vraag het maar gewoon.
Ik ga zeer binnenkort aan mijn eerste echt grote project beginnen, looptijd van ongeveer 9 maanden. Veel van deze tijd zal gebruikt worden voor het systematisch afwerken van testscripts, omdat het een applicatie is die binnen de verzekeringssector gebruikt zal gaan worden door ondernemers (het online maken van het naverrekeningstraject, dit is het aanpassen van bepaalde waarden zodat de premiehoogte bijgesteld kan worden).

Officieel start het traject pas in januari, maar aangezien ik er liever een poosje langer over nadenk ben ik mezelf bezig gaan houden met het uitdokteren van een goede architectuur.

Het gaat overigens om een C# project, ondersteunt met een MS SQL Server 2005 database.

Goed, stukje brainfart.

1) maak ik voor elke tabel in de database een entiteitsbestand aan, zodat ik mijn relationele model redelijk kan vertalen naar een Object:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// stel je even de klasse Foobar voor
// met 2 members: foo en bar
public class Foobar 
{
    private int id = -1;
    private string foo = String.Empty;
    private string bar = String.Empty;
    
    Id
    {
        get { return value; }
    }
    Foo
    {
        set { foo = value; }
        get { return foo; }
    }

    Bar
    {
        set { bar = value; }
        get { return bar; }
    }
}


2) Ik maak een general database access klasse. Deze klasse weet in feite niets van de applicatie, hij leest de connectionstring uit een configuratiebestand (web.config oid), verbindt met de database. Hij verwacht een parameter, namelijk de naam van een stored procedure of, afhankelijk van het type query, een dynamic generated query. Een geeft een DataSet, DataReader of DataTable terug (nog niet helemaal over uit), wat gelijk staat aan een java ResultSet. Deze klasse wil ik als static singleton implementeren, zodat er niet onnodig verbindingen naar de database openstaan (ook al heb je een GC) en het op klasseniveau te benaderen is.

3) Deze Objecten die 2 teruggeeft dienen natuurlijk omgezet te worden naar de juiste objecten, deze klassen zorgen ervoor dat dit gebeurt. Een DataSet met 2 klant objecten geeft een datastructuur terug met 2 Klant objecten. In het geval van Foobar gaat deze klasse FoobarDataAccess heten. En implementeerd verschillende eisen mbt het ophalen van data bv:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// pseudo/lossevinger werk
// punt is om een loosely type datarow in een object te laten veranderen
public class FoobarDataAccess
{
    public HashTable<FooBar> FetchAllFoobar()
    {
        HashTable<FooBar> retTable = new HashTable<FooBar>();
        DataTable dt = GeneralDB.GetRecords("naam van stored procedure");
        foreach(DataRow dr in dt.Rows)
        {
            FooBar fb = new FooBar();
            fb.Id = dr["id"];
            fb.Foo = dr["foo"];
            fb.Bar = dr["bar"];
            retTable.add(fb);
        }
        return retTable;
    }

    public FooBar GetFooBarById(int id)   
    {
        FooBar fb = new FooBar();
        DataRow dr = GeneralDB.GetRecord("naam van stored procedure", id);
       // weer een mapping naa het object
    }


Mijn vraag, ga ik zo juist met de abstracties om, liggen de verantwoordelijkheden op deze manier goed?
Is dit uberhaupt handig, ik kan me voorstellen dat ik in m'n business layer een enorme chaos aan rondslingerende objecten ga creeren
Stel dat FooBar een 1-n relatie heeft met FussBarr, hoe ga ik dan op de juiste manier met de joins om? Welke klasse heeft die verantwoordelijkheid? Sla ik gewoon een FooBar object op en zoek ik er later een FussBarr collectie bij op?

Ik weet dat ik een ORMapper of XSD oid dan gebruiken, maar wil eerst de kneepjes leren kennen voor ik truukjes ga toepassen :)

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:07
Ik zou toch al direct eens kijken naar een O/R mapper. Dat zijn helemaal geen truukjes, alleen hulpmiddelen die je een hoop werk en kopzorgen kunnen besparen.

Als je dat toch niet wilt doen, dan heb ik een vraagje voor je mbt puntje 2:
Hoe ga je die DB class laten werken met transacties ? Wat als je meerdere queries binnen één transactie wilt afhandelen ? Hoe ga je dat doen ?

[ Voor 41% gewijzigd door whoami op 05-11-2007 14:06 ]

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Hmm, tja daar zou ik natuurlijk een Transactieobject voor kunnen schrijven.
In dit object zitten dan de verschillende queries, die sequentieel uitgevoerd worden.
Of op gezette tijden een batch transacties achter elkaar uit laten voeren, bijvoorbeeld midden in de nacht. Waarbij natuurlijk wel heel goed in de gaten gehouden moet worden welke volgorde aangehouden dient te worden.

Maar jij zou een tool als LLBLGen of NHibernate aanraden eigenlijk?

[ Voor 13% gewijzigd door Verwijderd op 05-11-2007 14:20 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Verwijderd schreef op maandag 05 november 2007 @ 14:18:
Hmm, tja daar zou ik natuurlijk een Transactieobject voor kunnen schrijven.
In dit object zitten dan de verschillende queries, die sequentieel uitgevoerd worden.
Of op gezette tijden een batch transacties achter elkaar uit laten voeren, bijvoorbeeld midden in de nacht. Waarbij natuurlijk wel heel goed in de gaten gehouden moet worden welke volgorde aangehouden dient te worden.

Maar jij zou een tool als LLBLGen of NHibernate aanraden eigenlijk?
Als jij het je baas kunt verantwoorden waarom jij significant veel tijd van wat beschikbaar is voor dit project gaat besteden aan het schrijven van een data-layer, debuggen ervan en onderhouden ervan (vergeet ook de documentatie niet), terwijl er spullen op de markt zijn waar al 5 jaar (of meer) werk in gestoken is en die in duizenden en duizenden applicaties over de gehele wereld elke dag weer bewijzen dat de bugs, indien ze er zijn, zo langzamerhand alleen nog in de echte edge cases te vinden kunnen zijn (if any), dan moet je dat natuurlijk vooral doen. :)

Maar ik zou die tijd fijn spenderen aan dingen voor het project, zoals het schrijven van de applicatie zelf, zodat je zeker weet dat je binnen budget blijft en op tijd klaar bent.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Dat snap ik heel goed, maar ik zou er juist graag wat meer vanaf weten, vind het namelijk best interessante materie.
Overigens ben ik parttime werkstudent en vind ik het ook niet erg om thuis een beetje te knutselen (zoals nu) :)

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Verwijderd schreef op maandag 05 november 2007 @ 15:05:
Dat snap ik heel goed, maar ik zou er juist graag wat meer vanaf weten, vind het namelijk best interessante materie.
Overigens ben ik parttime werkstudent en vind ik het ook niet erg om thuis een beetje te knutselen (zoals nu) :)
Ok, niet boos worden nu.

'Knutselen' is iets voor de hobbykamer. Professioneel software development waar klanten echt DIK geld voor betalen (ga maar eens narekenen wat die klanten gaan betalen voor 9 maanden custom software bouw) heeft NIETS met knutselen te maken en de gedachte alleen al dat je knutselend (en sorry, dus prutsend) spullen probeert te bouwen die wellicht eindigen in de software waar veel geld voor is neergelegd is op zijn zachtst gezegd onacceptabel. Je bent nog student, allemaal niet erg, maar hou altijd goed in het achterhoofd dat wat jij maakt dat daar wellicht veel geld voor betaald is en dat men dus professioneel spul verwacht en geen gehobby en geen gepruts noch geknutsel.

Verder is de materie natuurlijk erg interessant, maar dan zou ik een project waar wellicht tonnen voor betaald wordt niet gebruiken om daar wat 'uit te proberen' en wat onderzoek te doen hoe en wat. Dat grote consultancy firma's nog steeds denken dat dat best kan moeten zij weten, het maakt het vak Software Engineer gewoon kapot.

Dus, wil je gewoon meer weten van hoe je een o/r mapper maakt, dan is dat natuurlijk niet erg. Het is wel erg veel werk. Sommigen denken weg te komen met een slappe DAL layer waar initieel niet zoveel werk in wordt gestoken maar gaandeweg het project blijkt deze niet zo toereikend en worden er allerlei dingen aangebroddeld. Vergeet niet dat je DAL de service laag is waar veel gebruik van gemaakt wordt het fundament van je verdere applicatie, dus wil je dat uberhaupt starten dan zul je toch moeten weten wat je DAL gaat doen hoe deze werkt etc.

Neem van mij aan: een generieke dal maken die het project aankan zonder dat je halverwege de boel moet herzien etc. kost gewoon veel tijd. In LLBLGen Pro zit gewoon meer dan 8 manjaar werk en het complete project beslaat meer dan 300.000 regels code. Die heb je niet allemaal nodig om iets te maken specifiek voor een project, alleen is het nadeel dat je niet vooraf weet WELKE subset je nodig hebt voor het project. Alleen al SQL genereren voor een bepaalde DB uit een query API (al nagedacht daarover ? ) is iets wat je niet 1 2 3 goed krijgt, je loopt hoe dan ook op tegen allerlei details. Hoe entities te saven in de juiste volgorde, hoe fk's met pk's te syncen, hoe events te raisen zodat je databinding werkt etc. etc. Erg veel werk, veel testen en dus kost het gewoon bakken met tijd en dus geld.

Voor de onderliggende theorie van o/r mapping, entities gebruik in je applicatie etc. verwijs ik je naar 2 artikelen. 1 is van mezelf, en stond ook in het boek van Jimmy Nilsson, Applying Domain Driven Design and Patterns:
The datamodel is the domain model. Over het verschil tussen abstracte entities, entity classes, tables, data in een table etc.

De 2e is van Scott Ambler, en dat is het standaard werk hoe een o/r mapper te maken:
http://www.agiledata.org/essays/mappingObjects.html

(via de wikipedia page: http://en.wikipedia.org/wiki/Object_Relational_Mapping)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Voor een algemeen inzicht in dit soort problematiek verwijs ik nog steeds naar het werk van Martin Fowler: Patterns of Enterprise Application Architecture. Het is nog steeds een erg actueel boek. Eventueel zou je het kunnen combineren met Domain Driven Design van Erik Evans.

Ik ben verder niet bekend met de kwaliteit van NHibernate, maar Hibernate is op het Java platform 'de' or mapper. Er is verder erg veel documentatie over te vinden. Ik weet niet hoe ver NHibernate out of sync loopt met Hibernate. Je zou verder ook kunnen kijken naar Spring.NET. Onder Java is Spring wel een van de bekendste applicatie frameworks, dus wellicht dat Spring.NET onder .NET ook prettig is.

[ Voor 42% gewijzigd door Alarmnummer op 05-11-2007 16:44 ]


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:07
Alarmnummer schreef op maandag 05 november 2007 @ 16:41:
Voor een algemeen inzicht in dit soort problematiek verwijs ik nog steeds naar het werk van Martin Fowler: Patterns of Enterprise Application Architecture. Het is nog steeds een erg actueel boek. Eventueel zou je het kunnen combineren met Domain Driven Design van Erik Evans.
Ook mijn idee. :)
Ik ben verder niet bekend met de kwaliteit van NHibernate, maar Hibernate is op het Java platform 'de' or mapper. Er is verder erg veel documentatie over te vinden. Ik weet niet hoe ver NHibernate out of sync loopt met Hibernate. Je zou verder ook kunnen kijken naar Spring.NET. Onder Java is Spring wel een van de bekendste applicatie frameworks, dus wellicht dat Spring.NET onder .NET ook prettig is.
NHibernate wordt in .NET ook veel gebruikt. Als alternatief voor Spring.NET kan je ook eens kijken naar Castle Windsor, en evt naar Castle ActiveRecord. Dat laatste is een implementatie van het ActiveRecord pattern, waarbij gebruik gemaakt wordt van NHibernate.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ok, niet boos worden nu.
Ik word niet zo snel boos, ik ga ervan uit dat je alleen maar goed advies wil geven en dat waardeer ik.

Goed en wel beschouwd moet ik me inderdaad eerst maar eens wat vollediger in gaan lezen in de materie. En laat ik het knutselen maar beperkt tot het zolderkamertje. Iets zegt me dat ik waarschijnlijk nog legio dingen over het hoofd ga zien (concurrency, locking etc) wat niet echt handig is in een productieomgeving.
Anderzijds voel ik me enthousiast om me daar in te verdiepen en dat ga ik ook zeker doen, zonder de druk van 'echt' werk :)

Tijd om me maar eens te verdiepen in NHibernate en LLBLGen ;)

[ Voor 10% gewijzigd door Verwijderd op 05-11-2007 17:01 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik vraag me iets af, maar ik denk dat hier niet echt een duidelijke regelgeving voor te maken valt.
Een applicatie gaat veel queries op de database doen, dus lijkt het me een goed idee om een soort objectcache te maken (wat het misschien helemaal niet is, so correct me...) hier wil ik dus datastructuren in onthouden met daarin objects, als er dan een transactie op uitgevoerd is moet de cache worden geupdate middels een query.
Mijn gedachte hier achter is dat er minder met de database gecommuniceerd hoeft te worden, althans minder vaak, om zo een performance winst op te leveren (mind you dat dit wel gewoon een hersenspinsel is, het staat nog niet eens op (klad)papier, en waar kan ik m'n hersenspinsels beter af laten schieten dan op GoT :9 ).

Maar ja, hoe ga je nou bepalen welke objecten in aanmerking komen voor de cache?

Mijn eerste gedachte is dan dat de applicatie eigenlijk met een lege cache begint, naar mate de applicatie meer gebruikt wordt, word bekend welke tabellen vaker, ten opzichte van de andere, worden aangesproken.

Die cache moet natuurlijk niet tot in de extreme kunnen groeien, dus het lijkt me verstandig deze een maximale grootte te laten hebben, een percentage van het aanwezige fysieke geheugen (maar wat is hier een goede leidraad, ik kan wel roepen 1%, maar het blijft roepen).
Wel levert dit weer het probleem dat de grootte van de cache elke keer na een update bepaalt moet worden, waarna ik de minst gebruikte van de actuele cache kan verwijderen uit de cache.

Wat is een goede manier om de grootte van het cache object te bepalen, stel dat dit een keyvalue collection is, moet ik dus door de collectie itereren en proberen op alle 'subobjecten' en hun 'subobjecten' een SizeOf operatie toe te passen, wat weer problemen met private fields oplevert óf ik laat het object serializen waarna ik de bestandsgrootte hiervan bepaal (wat weer disk IO oplevert).

Verder moet er een soort van locking op de objects in de cache komen, en je moet rekening houden met queries die dingen in de cache én de database aanspreken, concurrency moet dus goed in de gaten gehouden worden.

Ik kan me zo voorstellen dat het een hoop overhead oplevert en als het een beetje verkeerd uitpakt een enorme memory footprint met als resultaat een trage bende ;)

Punt van de post, voor ik dingen concreet op papier ga zetten (laat staan codekloppen) vraag ik me dus af of een dergelijke methode een goede aanpak is?

Overigens ben ik er wel achter gekomen dat de materie veel complexer is dan ik in eerste instantie dacht, ik denk er dan ook echt niet eens meer over mijn eigen baksels op te nemen in productiecode :+

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Verwijderd schreef op zaterdag 01 december 2007 @ 20:09:
Ik vraag me iets af, maar ik denk dat hier niet echt een duidelijke regelgeving voor te maken valt.
Een applicatie gaat veel queries op de database doen, dus lijkt het me een goed idee om een soort objectcache te maken (wat het misschien helemaal niet is, so correct me...) hier wil ik dus datastructuren in onthouden met daarin objects, als er dan een transactie op uitgevoerd is moet de cache worden geupdate middels een query.
Mijn gedachte hier achter is dat er minder met de database gecommuniceerd hoeft te worden, althans minder vaak, om zo een performance winst op te leveren (mind you dat dit wel gewoon een hersenspinsel is, het staat nog niet eens op (klad)papier, en waar kan ik m'n hersenspinsels beter af laten schieten dan op GoT :9 ).

Maar ja, hoe ga je nou bepalen welke objecten in aanmerking komen voor de cache?
Caching voor performance is onzin.
http://weblogs.asp.net/fb...ch-data-faster_2E00_.aspx

Het punt is dat je alleen bij single entity met PK filter fetches kunt gaan kijken in de cache en in alle andere gevallen je ALTIJD naar de database moet, daarna de set ophalen en DAARNA de cache bijwerken. Dit KOST alleen maar performance.

Tuurlijk, wanneer je de ogen sluit voor staleness van data, en je bij een identieke query gewoon dezelfde set objects returned, tja, dan levert het wat op. Maar dat soort zaken zijn niet echt te prefereren, want ga jij beslissingen nemen op basis van data die jij uit de cache haalt terwijl je niet weet of die entities niet zijn geupdate door een andere thread in de database?
Mijn eerste gedachte is dan dat de applicatie eigenlijk met een lege cache begint, naar mate de applicatie meer gebruikt wordt, word bekend welke tabellen vaker, ten opzichte van de andere, worden aangesproken.
Je moet niet denken in code, maar in een abstractielaag daarboven. Als je ook nog begint met het analyseren van wat je problemen zijn, kun je DAARNA besluiten wat de oplossingen zijn .

Als je dat goed doet, kom je erachter dat je helemaal geen cache nodig hebt, want die werkt nl helemaal niet performance verhogend.

Denk je echter in code en welke dingen je in CODE aan het doen bent, dan kun je allerlei problemen gaan zien die er helemaal niet zijn.

Een cache is verder alleen nuttig in-process, en dan ook nog alleen voor single entity PK fetches. Je hebt bv snakeoil fabrikanten die een netwerk cache verkopen, en dan heb je het over een verkapte object database, maar wel eentje die redundant data in zich heeft. Een RDBMS heeft nl. OOK nog een cache. En omdat je je objects over een netwerk lijntje moet marshallen/serializen, levert het per saldo geen ene moer op.
Punt van de post, voor ik dingen concreet op papier ga zetten (laat staan codekloppen) vraag ik me dus af of een dergelijke methode een goede aanpak is?
Als je nou eens begint met de analyse van het probleem dat je hebt, daar dan oplossingen voor gaat verzinnen en DAARNA pas die oplossingen naar code (!) gaat omzetten en niet eerder (dus die oplossingen zijn niet 'code', maar algorithmes), wellicht kom je dan op dingen uit die je wel vooruit helpen. :)
Overigens ben ik er wel achter gekomen dat de materie veel complexer is dan ik in eerste instantie dacht, ik denk er dan ook echt niet eens meer over mijn eigen baksels op te nemen in productiecode :+
Het is inderdaad niet zo simpel als menig nitwitt je wil doen geloven. :) Tuurlijk een query uitvoeren en de datareader data in objects stoppen, dat is voor velen nog wel te doen. Maar dat is ook niet de moeilijkheid van de materie, het is de rest :)

Btw, over het caching artikel: ik heb wat weerwoord daarop gekregen, maar geen 1 persoon kon aantonen dat caching performanceverhogend werkt. Laat je daarom ook niks wijsmaken mbt 1st level, 2nd level caches en wat men al niet verzonnen heeft: ze werken alleen wanneer staleness geen punt is, en in bijna alle gevallen (behalve lookup data) is staleness nu juist wel belangrijk.

Ongeacht dat, veel queries zijn niet te cachen, bv get all customers with an order in june. Hoe weet je dat AL die customers in de cache zitten? dat weet je niet. Het punt is alleen: OF je haalt alle objects door de cache, OF je gebruikt GEEN cache. Je kunt niet parallel naast elkaar entities wel/niet uit de cache halen. Dat levert nl. veel extra overhead en complexiteit op.

[ Voor 9% gewijzigd door EfBe op 01-12-2007 20:28 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Als je nou eens begint met de analyse van het probleem dat je hebt, daar dan oplossingen voor gaat verzinnen en DAARNA pas die oplossingen naar code (!) gaat omzetten en niet eerder (dus die oplossingen zijn niet 'code', maar algorithmes), wellicht kom je dan op dingen uit die je wel vooruit helpen.
Heb je zeker gelijk in en ik probeer me ook steeds meer* op de analyse van problemen te richten (hoewel ik dat nog wel wat lastig vind, ervaring, ervaring).
Maar het is gewoon fijn om feedback te krijgen op gedachten, positief of negatief, uiteindelijk is het toch (veelal) opbouwende kritiek.

Acties:
  • 0 Henk 'm!

  • YopY
  • Registratie: September 2003
  • Laatst online: 13-07 01:14
Ik gebruik zelf wel een cache tussen mijn database (o/r mapper) en m'n data, maar dit is omdat er 'veel' (relatief begrip natuurlijk) gegevens bij de database objecten bijkomen wat een aantal seconden duurt om in te laden. Als in mijn geval de gegevens elke keer uit de database gehaald zou moeten worden, dan zou er bij elke request nog eens 300 tot 500 ms aan overhead bijkomen voor het parsen van een XML bestand.

Voor zo'n geval is een cache ideaal. In het geval van gewoon data uit de database halen is het echter wat minder ideaal: ik zou het gebruiken indien het bijvoorbeeld een complexe query is die lang duurt om uit te voeren (daar komt dan het probleem van het weer opzoeken in de cache bij), of bij een externe database waarbij de overdracht van query resultaten over het (inter)netwerk langer dan een acceptabele tijd duurt.

Het nadeel is echter dat je óf een grote hoeveelheid geheugen nodig hebt (afhankelijk van de data), óf een cache nodig hebt die de oudere objecten op de harde schijf opslaat wanneer er teveel geheugen gebruikt wordt.

Voor Java is er bijvoorbeeld ehcache, welke dat soort zaken automatisch afhandelt. Werkt ideaal, en bespaart uiteindelijk seconden rekenwerk terwijl je het geheugen en/of schijfgebruik precies kunt regelen.

Maar het gebruik van een cache is sowieso afhankelijk van de situatie. Ik zou zeggen, probeer het eerst zonder cache en kijk hoe lang database queries duren. Indien ze onacceptabel lang duren (ook weer afhankelijk van de situatie, hoeveelheid gegevens, complexiteit van query), of indien er vaak een request voor precies dezelfde gegevens zijn, dan pas zou je moeten kijken naar een cache.

En voordat je je eigen cache gaat bouwen, zoek eerst eens of er al een op het internet te vinden is - goeie kans dat er al een goeie cache voor jouw doeleinden zijn, en een nog betere kans dat het beter is dan jij ooit kunt maken, zelfs in de 9 maanden.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Mijn doeleinden zijn het zelf nadenken over de ontwikkeling van een dergelijke applicatie, dus als ik dan premade software van derden ga toevoegen sla ik de plank voor mezelf een beetje mis :)
Ik tracht een zo generiek mogelijke layer/generator/mapper te maken (hoewel ik nog niet veel verder ben dan requirements e.d. opstellen en zo nu en dan even met een ideetje spelen ivm. tijdgebrek :() dus het moet zo breed mogelijk toepasbaar zijn.

[ Voor 5% gewijzigd door Verwijderd op 03-12-2007 16:53 ]


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Ben ik met je oneens. Een van de technieken die we het eerst toepassen is caching van data dat niet al te vaak wordt geupdate. Daar zit al vaak behoorlijk wat winst te halen voor maar relatief weinig inspanning. In HIbernate heb je het met een paar regels voor elkaar.
Tuurlijk, wanneer je de ogen sluit voor staleness van data, en je bij een identieke query gewoon dezelfde set objects returned, tja, dan levert het wat op. Maar dat soort zaken zijn niet echt te prefereren, want ga jij beslissingen nemen op basis van data die jij uit de cache haalt terwijl je niet weet of die entities niet zijn geupdate door een andere thread in de database?
Daarvoor bestaat er zoiets als optimistic locking. In veel gevallen is het helemaal niet noodzakelijk dat een gebruiker of ander systeem de meest actuele informatie ziet (mag best een paar minuten oud zijn).

Je komt hier in de rest van je reply wel op terug, maar om caching nu meteen af te schieten gaat me toch een beetje te ver. Out of date data met eventueel optimistic locking is een hele goeie manier om de database als performance/schaalbaarheids bottleneck in je systeem te verwijderen. Moderne grid oplossingen (Terracotta, Oracle/Tangosol Coherence, Gigaspaces) zijn in principe niets anders dan distributed heap en zijn erg goed in te zetten als cache (ze doen het goed en zijn veel goedkoper dan Oracle RAC of andere (te) dure software).
Pagina: 1