VB & drie-lagen-structuur

[pkouwer]

Microschoft beveelt het programmeren volgens de three-N-tier structuur (verbeter me als ik het mis heb). Dit betekent applicatie (UserInterf.) - Buisiness Rules - database (event. met koppeling).

Wat ik me nou afvraag (ben newbie op dit gebied), wat verstaat men nu precies onder 'Business Rules' ? Heeft het uberhaupt zin om zo te programmeren en wat valt er nog meer onder deze 'tweede laag'.

Stel: ik plaats alle databasefuncties in een DLL, wat zijn dan de voor- en nadelen van deze werkwijze ?

thnx!

[farlane]

De tweede laag is je eigenlijke applicatielogica.

[pkouwer]

plaats je dit ook in DLL's of hoe moet ik die drieeling zien in VB6 ?

[RobzQ]

Op woensdag 26 juni 2002 12:55 schreef pkouwer het volgende:
plaats je dit ook in DLL's of hoe moet ik die drieeling zien in VB6 ?

Meestal zie je een constructie als:

Clientcode -> Servercode -> Database

De client staat bij de eind gebruik op de desktop en bevat niet te veel logica. Optimaal is een dunnen schil op de client en de meeste logica op de server leggen.

Servercode staat dan idd ergens op een server, centrale plek op het netwerk en bevat de meeste logica, haalt de data op uit de db enz. enz.

De database bevat natuurlijk de data.

Overigens is VB6 niet optimaal om multitier te werken maar het werkt wel. VB.Net is wel klaar voor 'echte' multitier applicaties.

[pkouwer]

punt is het worden geen C-S applicaties, maar desktopapps.

[farlane]

Het _kan_ in aparte applicaties, maar het is voornamelijk een kwestie van structuur in je programma aanbrengen.

Dwz dat je geen applicatielogica hebt zitten onder formulieren ed (Wat voor een VB programmeur vrij lastig schijnt te zijn ).

Er zijn btw een aantal mooie technieken en patterns om dit te realiseren.

[pkouwer]

welke technieken zoal ? Ben geintereseerd hierin..

[farlane]

o.a model-view-controller pattern en nog vele anderen

model-view-controller

Zie ook:
Zoekt en gij zult vinden

En het boek:
Het boek

[Verwijderd]

naar de MSDN site (msdn.microsoft.com) en dan op windows DNA zoeken.

Verder is het 'microsoft' en niet 'microschoft'. Jij wordt ook niet sukkel genoemd omdat je een inkopvraag niet weet, of wel?

[pkouwer]

daar ben je toch newbie voor, of niet soms. Verder is Microschoft mijn mening en als mensen mij een sukkel willen noemen omdat ik een, volgens jou, inkopvraag niet weet, so what. Ik lig er echt niet wakker van. Slaap misschien nog wel beter dan dat ik al doe.

ps DNA is voor Internet-gebruik, wil ik helemaal niet. Puur desktop apps.

[.oisyn]

Op woensdag 26 juni 2002 19:23 schreef pkouwer het volgende:
daar ben je toch newbie voor, of niet soms. Verder is Microschoft mijn mening en als mensen mij een sukkel willen noemen omdat ik een, volgens jou, inkopvraag niet weet, so what. Ik lig er echt niet wakker van. Slaap misschien nog wel beter dan dat ik al doe.

mening of niet, het blijft gewoon een dikke troll, en daar zijn we niet van gediend, dus ik zou je willen verzoeken dit niet meer te doen

je mening geven mag natuurlijk altijd, maar onderbouw het dan goed en doe geen loze uitspraken, dat lokt alleen maar verkeerde reacties uit

[Verwijderd]

Op woensdag 26 juni 2002 19:23 schreef pkouwer het volgende:
daar ben je toch newbie voor, of niet soms. Verder is Microschoft mijn mening en als mensen mij een sukkel willen noemen omdat ik een, volgens jou, inkopvraag niet weet, so what. Ik lig er echt niet wakker van. Slaap misschien nog wel beter dan dat ik al doe.

Sjonge wat hebben we het weer begrepen.

ps DNA is voor Internet-gebruik, wil ik helemaal niet. Puur desktop apps.

Is niet voor internetgebruik. DNA is gui - businesslogic - data. Wat die gui is doet er niet toe. Dat jij die link niet legt, geeft aan dat je wel hard mag roepen over microschoft e.d. maar je schiet toch aardig te kort vwb de materie mbt client-server applicaties. Daar bij microsCHoft hebben ze dat aardig beter door.

[pkouwer]

heb ook nooit beweerd dat ik daar kennis van heb. Maar ach. JIJ bent natuurlijk dé man/vrouw die echt ALLES weet. zo blijkt wel...

[pkouwer]

maar goed, genoeg stom gezeik gehad. OK, excuses voor Micro-dinges.

Waar ik naar toe wil is dat ik niet goed kan bevatten wat er precies onder business-rules verstaan wordt en hoe ik dit vertaal naar VB. De connectie met de database kan ik op zich nog wel begrijpen, maar ook hier geldt: hoe in VB bijvoorbeeld.

We spreken dus alleen over desktop apps, eventueel met een database (Access, MySQL) ergens in een netwerk, that's it.

[Janoz]

Waar het eignelijk op neer komt is dat je applicatie volledig zou moeten kunnen functioneren zonder dat er een GUI aan zit. Met de huidige sleur en pleur mentaliteit is dat mischien wat lastig te bevatten.

Voor je applicatie maakt het niet uit of je met een commandline, geile gui of webinterface werkt.

Waar het eigenlijk op neer komt is dat het drukken op een knop geen programma logica moet uitvoeren, maar een methode in je applicatie moet aanroepen die vervolgens die logica uitvoerd.

_{De Microsoft Microschoft m$ of wat dan ook uitspraken doe we maar gewoon in de HK. Je mag best zeggen dat je (bv) een hekel aan de hungarian coding style hebt, maar hier in PW noemen we de beestjes gewoon bij hun naam.}

[pkouwer]

OK, got it.

Maar wat ik hier wel eens heb gelezen over versienummering dat bv data.dll deel nam in de nummering bv versie 3.2.6 (6 = de versie van data.dll). Volgens mij worden dus de database-aanroepen in een DLL geplaatst. Vraag is welk nut heeft dit en zou dit voor de business rules wel/niet/misschien van toepassing zijn ?

[Janoz]

Door deze drie te scheiden kun je heel simpel de mogelijkheden van je programma aanpassen. Stel bijvoorbeeld data.dll. Deze bied een soort view aan je applicatie op de database. Nemen we het voorbeeld van een forum, dan heeft data.dll bijvoorbeeld een functie getActiveTopics() oid. Je applicatie maakt het verder geen reet uit hoe deze topics op worden gehaald. Waneer je nu data.dll heb gebaseerd op mysql, maar je wilt met een flatfile gaan werken of een veel efficienter, maar compleet ander database model, dan hoef je alleen de methoden in data.dll aan te passen/uit te breiden. Zolang je applicatie maar hetzelfde antwoord terugkrijgt als het anders ook altijd terugkreeg is er voor de rest van je programma niks aan de hand.

Hetzelfde geld voor de GUI kant. Als je de layout van de GUI compleet omgooit heeft dit geen enkele invloed op de werking van je applicatie. Zolang de juiste methoden in je applicatie maar aangeroepen worden en de juiste uitkomsten op 1 of andere manier overgebracht worden naar de gebruiker.

[Verwijderd]

Op woensdag 26 juni 2002 22:03 schreef pkouwer het volgende:
Waar ik naar toe wil is dat ik niet goed kan bevatten wat er precies onder business-rules verstaan wordt en hoe ik dit vertaal naar VB. De connectie met de database kan ik op zich nog wel begrijpen, maar ook hier geldt: hoe in VB bijvoorbeeld.
We spreken dus alleen over desktop apps, eventueel met een database (Access, MySQL) ergens in een netwerk, that's it.

Dat heet een 'fat client'. In de tijden van weleer (dat is dus vorig jaar) had je een dikke client (een executable met alle logica) en een database. Dit is niet schaalbaar, want als je de logica die in de fat client zit wilt gebruiken in een andere app, dan kan dat niet.

Wat hebben ze toen bedacht? Een ander client-server model: men slankt de fat-client wat af, en creeert een tussenlaag tussen de client, dus de executable, en de database. (voor de executable kun je ook een webapplicatie zien of een applicatie op een handheld oid, die communiceert met een groter systeem). De logica die nodig is voor de client zelf, dus schermbesturing, gebruikerinteractie afhandeling en data-manipulatie voor weergave / early dataprocessing van de input van de gebruiker voor de database, wordt in de client ingebakken. De logica die nodig is voor de applicatie, dus die de applicatie zelf vormt, stop je nu niet meer in de client zelf maar in components. Die components (in VB maak je dan een ActiveX dll, dus COM components) installeer je bv in COM+ services op een Win2k doos in je netwerk. Die components bevatten de feitelijke logica van de applicatie en maken contact met de database. De client maakt alleen contact met de components. Het voordeel hiervan is, is dat je andere clients, met dezelfde components kunt laten praten, dus je hergebruikt je programmatuur. Verder kun je de components en de database centraal in je organisatie neerplanten op een grote machine, terwijl degene die met de client werkt gewoon op een klein PC-tje werkt.

[XTerm]

Ik heb dit intuïtief teogepast op mijn eindwerk.

Alle database aanroepen zitten in een klasse, en de formuliercode roept gewoon een function aan.

Uiteraard GPL : Sims 0.1.2-pre1