[Vb.net] N-Tier applicatie

[Sven_Vdb]

Ik ben dus bezig met een nieuw programma te schrijven. Maar ben nu aan het kijken wat de beste
Performance / aanpasbaarheid verhouding is.
Ik lees op de ene site/blog dat n-tier(bussines entitie / dataaccess) niet altijd optimaal zijn i.v.m snelheid?
Op andere site's prijzen ze dan weer het n-tier model hoog in het vaandel.

Wat zijn jullie "professionele" ervaring hiermee?
Bedenk wel dat er enkele 100 000 ( tot een aantal miljoenen records in de database kunnen komen ).

[whoami]

Sven_Vdb schreef op vrijdag 01 mei 2009 @ 23:15:
Ik ben dus bezig met een nieuw programma te schrijven. Maar ben nu aan het kijken wat de beste
Performance / aanpasbaarheid verhouding is.
Ik lees op de ene site/blog dat n-tier(bussines entitie / dataaccess) niet altijd optimaal zijn i.v.m snelheid?
Op andere site's prijzen ze dan weer het n-tier model hoog in het vaandel.

Wat zijn jullie "professionele" ervaring hiermee?

Alles hangt af van de applicatie en het doel.
Grote / complexe applicatie vs hobby projectje;
Aanpasbaarheid / time-to market
etc...
allemaal factoren die meespelen.

Bedenk wel dat er enkele 100 000 ( tot een aantal miljoenen records in de database kunnen komen ).

Dat heeft niets te maken met het toepassen van een n-tier model; zorg er zowiezo voor dat je DB design goed is.

[Woy]

Het hangt inderdaad af van je applicatie wat je precies gaat doen. Maar een N-Tier applicatie meteen afschrijven omdat de performance niet goed is, is IMHO niet de juiste reden.

Het hoeft totaal geen probleem te zijn om 100.000 tot miljoenen records in je database te stoppen. Een applicatie die is op gezet als N-Tier zal inderdaad misschien een klein beetje extra overhead hebben, maar dat weegt niet op tegen design fouten in je database. Een fout in je database kan meteen je hele performance om zeep helpen, terwijl je grote kans hebt dat je de eventuele overhead van een N-Tier design niet eens zal merken.

[OMX2000]

Professioneel advies Da's altijd wel lastig, ken genoeg profs die beter amateur hadden kunnen blijven. En er zijn genoeg hobbyisten die heeel professioneel bezig zijn.

Maar da's denk ik niet je vraag. Je wilt weten van mensen die doen alsof ze er verstand van hebben wat de beste oplossing is... En surprise, die is er niet.

Voor de duidelijkheid, N-Tier is niet hetzelfde als multi-layered. N-Tier heeft vooral te maken met hoe je applicatie gedraait wordt (meerdere processen, eventueel over meerdere servers verspreid) . En multi-layered is applicatie design (presentatie, business logica, data opslag). Dus N-Tier = fysiek, multi-layered = logisch.

Maar ok, ik zal wat uitgangspunten aannemen. Anders wordt dit ook zo'n flauwe post. Je wilt dus weten wat de beste verhouding is in aanpasbaarheid en performance. Die twee eigenschappen hoeven niet haaks op elkaar te zijn. Voorbeeld.. Een single tier (spaghetti) applicatie, kan heeeel snel zijn. Alle data is globaal toegangelijk, en je hebt geen restricties om bij data te komen;alles is globaal. De toepassing draait op 1 machine, en wordt maar door een gebruiker tegelijk gebruikt. Maar wat nou als je opeens veel meer gebruikers wilt ondersteunen, en je loopt tegen een capacitieitslimiet aan van je hardware? Of je komt erachter dat de opslag van data te langzaam gaat. Hoe schaalt je applicatie dan?

Uit het oogpunt van design zijn meerdere lagen welkom. Dat maakt de overzichtelijkheid van je code een stuk groter. Daarbij kunnen spelregels je helpen bij het netjes houden van je applicatie. Voorbeelden : Data layer mag niet de UI layer gebruiken. UI layer mag wel de business logic layer aanspreken. Geen business logica in UI layer.

Dus als jij zegt, de database kan wel 100.000 to 1 miljoen records bevatten. Zeg je dus impliciet, dat je voorziet dat je database een stuk groter kan worden dan initieel het geval is. Dus dan kom je redelijk snel (in de praktijk automatisch) op een database server, en hup daar heb je je eerste tier te pakken. Ik ga er ook ff vanuit dat je een UI hebt die niet door de database wordt aangeboden, dus dat zijn 2 tiers. Da's dus makkelijk. Maar nu moet je bepalen of je een derde tier nodig hebt?
Je hebt in ieder geval al wel 2 layers (UI en Data logic). Als je applicatie vooral CRUD is en je kunt allerlei restricties (business logica zoals, een auto mag maar 1 stuur hebben) afdwingen in je database, zou je ermee weg kunnen komen om maar 2 layers te hebben. Maar als je applicatie redelijk veel business logica bevat, dan loont het zeker om een business logica laag te hebben. Dus dan zou je op 3 layers kunnen komen : UI->Business->Data.
Terug bij de vraag of je een 3e tier wilt? Da's afhankelijk van het feit hoe zwaar je business logica is, en dan bedoel ik zwaar in termen van cpu power, en of er bottlenecks ontstaan doordat je requests op je business logica niet parallel kunt verwerken. Zo ja, dan zorg je dat je een 3e tier hebt waar je je business logica in draait en die schaalbaar is opgezet (thread safe).

Over het algemeen (70% van de applicatie) zijn applicatie 2 tier, met UI en Business logica in 1 tier, en data logica in een andere tier.
Bij grote toepassingen, heb je vaak een multi tier oplossing. Verschillende business logica draait op dedicated servers (webservices bijv.). De UI (web) draait op meerdere webservers, en er zijn verschillende databronnen (verschillende databases, eventueel externe databronnen).

[Mr_Light]

Volgens mij is het enige alternatief dat dat je compationeerd en distributeerd. Misschien erg kort door de bocht om te zeggen - maar vraag me af of als je vraag moet stellen het antwoord niet al gegeven is.

Wat had je zelf als alternatief?

miljoenen records is niet echt schrikbarend - ook niets zeggend zonder dat je weet wat het gebruik er van is. Een miljoen log records wegschrijven en vergeten is toch degelijk wat anders dan 1 miljoen user records die allemaal 'gelijk' actief zijn.

[Spider.007]

Mr_Light schreef op zaterdag 02 mei 2009 @ 13:27:
Volgens mij is het enige alternatief dat dat je compationeerd en distributeerd. Misschien erg kort door de bocht om te zeggen - maar vraag me af of als je vraag moet stellen het antwoord niet al gegeven is.

Wat bedoel je met 'compationeerd'?

[Sven_Vdb]

Ik dacht aan een 3-tier applicatie.
1 Mijn UI ( Waar al mijn forms en dergelijke staan )
2 Maak ik een dll waarin mijn Bussines entitie ( objecten ) en mijn DataAcces laag waarin mijn query's en dergelijke instaan.

Maar ik heb al gemerkt dat in sommige gevallen ( bij andere programmeurs) dit zeer traag gaat.
Dat wanneer je 100 000 records hebt. Deze zeer snel uit de database komen in bussines entitie.
Maar dan om te databinden ( dit soms zeer lang kan duren ). Of deden deze mensen iets verkeerd?
En zou ik het dus zo ook kunnen gebruiken?

[Woy]

Sven_Vdb schreef op zaterdag 02 mei 2009 @ 15:05:
Ik dacht aan een 3-tier applicatie.
1 Mijn UI ( Waar al mijn forms en dergelijke staan )
2 Maak ik een dll waarin mijn Bussines entitie ( objecten ) en mijn DataAcces laag waarin mijn query's en dergelijke instaan.

Dat is inderdaad een regelmatig voorkomende structuur van een applicatie

Maar ik heb al gemerkt dat in sommige gevallen ( bij andere programmeurs) dit zeer traag gaat.
Dat wanneer je 100 000 records hebt. Deze zeer snel uit de database komen in bussines entitie.
Maar dan om te databinden ( dit soms zeer lang kan duren ). Of deden deze mensen iets verkeerd?
En zou ik het dus zo ook kunnen gebruiken?

Met zo weinig informatie is er weinig over te zeggen, maar het lijkt mij inderdaad dat die mensen wat verkeerd deden. Ze zullen dus eens moeten gaan profilen waar de vertraging in de applicatie vandaan komt.

[MrBucket]

Sven_Vdb schreef op zaterdag 02 mei 2009 @ 15:05:
Ik dacht aan een 3-tier applicatie.
1 Mijn UI ( Waar al mijn forms en dergelijke staan )
2 Maak ik een dll waarin mijn Bussines entitie ( objecten ) en mijn DataAcces laag waarin mijn query's en dergelijke instaan.

Lijkt me een goed uitgangspunt. Zoals al eerder aangegeven bestaat de ideale architectuur niet, maar zonder te weten wat de specifieke kenmerken van de applicatie zijn is het ook lastig om een betere opzet te verzinnen.

Maar ik heb al gemerkt dat in sommige gevallen ( bij andere programmeurs) dit zeer traag gaat.
Dat wanneer je 100 000 records hebt. Deze zeer snel uit de database komen in bussines entitie.
Maar dan om te databinden ( dit soms zeer lang kan duren ). Of deden deze mensen iets verkeerd?
En zou ik het dus zo ook kunnen gebruiken?

Dat heeft niet zozeer te maken met de architectuur als wel met de geboden functionaliteit van de applicatie. Feit is dat je gewoon geen 100000 records naar je client moet trekken, voor databinding of anderszins. Dat gaat niet performen, ongeacht je architectuur.

Dus als je tot de conclusie komt dat je gebruiker echt toegang moet hebben tot die 100000 records, biedt hem dan geen datatable waar hij door 100000 records heen moet scrollen, maar een zoekfunctie die max. 100 - 1000 records retourneert. Deze zoekfunctionaliteit implementeer je uiteraard zo dicht mogelijk (het liefst op) je database, zodat er niet zoveel data het lijntje over hoeft.

[Mr_Light]

Spider.007 schreef op zaterdag 02 mei 2009 @ 13:37:
[...]

Wat bedoel je met 'compationeerd'?

das geen nederlands woord he in de richting van opdelen/ordenen van data/werk en afhankelijkheden(soms is het 'goedkoper' om fouten te detecteren en de relatief weinig voorkomende fouten op te lossen - dan voor alles te voorkomen fouten ontstaan. optimistische aanpak etc.) slimmigheden met data lokaliteit en andere trucjes.

[pasz]

Sven_Vdb schreef op zaterdag 02 mei 2009 @ 15:05:
Ik dacht aan een 3-tier applicatie.
1 Mijn UI ( Waar al mijn forms en dergelijke staan )
2 Maak ik een dll waarin mijn Bussines entitie ( objecten ) en mijn DataAcces laag waarin mijn query's en dergelijke instaan.

Maar ik heb al gemerkt dat in sommige gevallen ( bij andere programmeurs) dit zeer traag gaat.
Dat wanneer je 100 000 records hebt. Deze zeer snel uit de database komen in bussines entitie.
Maar dan om te databinden ( dit soms zeer lang kan duren ). Of deden deze mensen iets verkeerd?
En zou ik het dus zo ook kunnen gebruiken?

Je opzet is prima. Bedenk echter dat je niet altijd alle records hoeft op te halen in je Data Access-laag. Juist hier kun je met slimme queries veel performance winst halen.

Je Data Access-laag haalt data uit je database en 'vertaalt' deze naar jouw Business Entities. Andersom kan de DAL je objecten opslaan in je database.

[Woy]

MrBucket schreef op zondag 03 mei 2009 @ 15:33:
Dat heeft niet zozeer te maken met de architectuur als wel met de geboden functionaliteit van de applicatie. Feit is dat je gewoon geen 100000 records naar je client moet trekken, voor databinding of anderszins. Dat gaat niet performen, ongeacht je architectuur.

Dat heeft inderdaad niet zoveel met de architectuur te maken, als je met een platte architectuur 100.000 records in één keer weer wil geven, en die dus in een keer ophaalt en bind, dan zal dat ook langzaam gaan. Je zult dan inderdaad iets van paging ( al vanaf de database ) willen implementeren.

[OMX2000]

Zoals door bijv Woy al is aangegeven, zou het best onhandig zijn om 100.000 (of miljoenen) records in je UI te gaan tonen, zonder paging toe te passen.

Maar volgens als je een meer gericht advies wilt, moet je toch echt wat meer vertellen over de soort data, en de soort bewerkingen die je wilt gaan doen.

Business entities "vullen" vanuit de datalaag zal heel snel gaan. Maar als jij redelijk wat business logica hebt (bewerkingen/berekeningen/business rules), kan daar de bottleneck ontstaan. Als je steeds heel veel data "door" je business laag moet halen, is dat misschien inefficient. En in sommige gevallen geeft caching dan een oplossing. Dus caching in de UI. Waarom? Omdat je daar de meeste context hebt, je weet op het hoogste niveau (UI layer) het beste wat de data inhoudt, en of het überhaupt zin heeft om te cachen.

[Sven_Vdb]

OMX2000 schreef op maandag 04 mei 2009 @ 10:06:
Zoals door bijv Woy al is aangegeven, zou het best onhandig zijn om 100.000 (of miljoenen) records in je UI te gaan tonen, zonder paging toe te passen.

Maar volgens als je een meer gericht advies wilt, moet je toch echt wat meer vertellen over de soort data, en de soort bewerkingen die je wilt gaan doen.

Business entities "vullen" vanuit de datalaag zal heel snel gaan. Maar als jij redelijk wat business logica hebt (bewerkingen/berekeningen/business rules), kan daar de bottleneck ontstaan. Als je steeds heel veel data "door" je business laag moet halen, is dat misschien inefficient. En in sommige gevallen geeft caching dan een oplossing. Dus caching in de UI. Waarom? Omdat je daar de meeste context hebt, je weet op het hoogste niveau (UI layer) het beste wat de data inhoudt, en of het überhaupt zin heeft om te cachen.

Het is voor een handig facturatie systeem te bouwen.
Dus artikels zijn een heel pak/maar dit zal nog meevallen.
Het zullen vooral de order line's zijn die veel data gaan trekken. Orderdetails worden opgehaald aan de hand van orderid. Dus dat is geen probleem.
Maar als je een selectie legt op orders zelf en een grote selectie wilt is het wel nodig dat dit snel gebeurd.

Hoe zouden jullie het dan doen?
Je haalt alle gegevens uit de database en je steekt deze allemaal in de Bussiness Entitie ( objecten dus ).
En nadien allemaal binden? In bv datagridview? Of gaat dit weer traag?