[Alg] Data access + Business logic, hoe?

[Lorn]

Ik ben bezig om te onderzoeken hoe ik een n-tier omgeving moet opzetten. Ik wil zo'n omgeving gaan implementeren binnen VB6 met als database MS SQL Server 2000. Ik heb verschillende artikelen gelezen van diverse mensen. Zo heb ik ondermeer de volgende pagina's gelezen:
- N-Tier Application Development with Microsoft.NET
- What is n-Tier Architecture
- A reminder on Three/Multi Tier/Layer Architecture
- Designing Data Tier Components and Passing Data Through Tiers
- Setting up a COM component project in Visual Basic 6

Verder heb ik (uiteraard) de verschillende topics hier op GoT gelezen die over DAL en BLL gaan. Helaas kom ik nergens de informatie tegen die ik zoek. Ik hoop daarom via dit topic misschien toch wat duidelijk te krijgen.

- DAL en BLL, aparte DLLs?
Implementeer je de DAL en BLL ieder in een aparte DLL? Wat als die twee DLLs nou niet op dezelfde machine komen te staan, hoe maak ik dan binnen de BLL een referentie aan naar de DAL?
Wat ik me ook afvraag is of je per business entity een DLL aanmaakt of dat je een algemene DAL/BLL DLL hebt met daarin verschillende classes per business entity.

- Plaatsing connectionstring
Ik zou nu een connectiestring maken door de gebruiker op te laten geven welke database en SQL login er gebruikt moeten worden. Omdat de presentatielaag zelf geen interactie heeft met de database lijkt dat niet zo heel zinnig. In de meeste voorbeelden zie je dan ook dat de DAL en BLL zelf de connectiestring laden uit een bestand. Opzich geen probleem natuurlijk maar hoe regel je dan de rechten op de SQL server? Ik neem aan dat dit dan niet meer gaat via SQL accounts.

- Wat plaats je waar?
Stel ik heb een tabel met persoonsgevens. Mijn applicatie biedt de mogelijkheid om een persoon toe te voegen. Als eis wordt er gesteld dat een persoon minimaal 16 jaar moet zijn. Als ik het goed heb begrepen gebeurd er ongeveer het volgende bij het toevoegen van een nieuw persoon:

- De presentatielaag stuurt de nieuwe persoonsgegevens door naar de BLL
- De BLL controleert aan de hand van de geboortedatum of de persoon wel 16 jaar of ouder is. Is de persoon jonger dan geeft de BLL door aan de presentatielaag dat de persoon niet voldoet aan de gestelde eisen
- Als de persoon wel 16 jaar of ouder is dan stuurt de BLL alle gegevens door aan de DAL. De DAL zorgt voor het daadwerkelijk plaatsen van de data in de database

Eigenlijk is de BLL dan niet heel veel meer dan een doorgeefluik. Klopt dat?

- Connection pooling
Om gebruik te maken van de ADO connection pooling maak je in het begin van je applicatie een connectie aan die je vervolgens weer sluit zonder het connectie object vrij te geven. Hoe gaat dit in een n-Tier omgeving? Laat je dit gebeuren bij het creeeren van de DAL?

Dit zijn zo'n beetje de zaken die ik nu tegen kom. Ik hoop dat er mensen zijn die me wat verder kunnen helpen. Alle hulp is welkom!

[RedRose]

Lorn schreef op 24 september 2004 @ 16:59:

- DAL en BLL, aparte DLLs?

Dat zou ik wel doen. Via DCOM/COM+ moeten ze dan met elkaar communiceren. De BL en de DAL zouden beide 'stateless' moeten zijn, waar ik mee bedoel dat ze aangeroepen worden om bepaalde taken te verrichten of informatie op te halen, maar dat ze niet continue 'open' staan. (ik kan dat niet goed uitleggen, EfBe / whoami kunnen dat beter).

- Plaatsing connectionstring

Bij je DAL en nergens anders.

- Wat plaats je waar?

Eigenlijk is de BLL dan niet heel veel meer dan een doorgeefluik. Klopt dat?

Je voorbeeld klopt ongeveer, alhoewel er geen vaste ijkpunten voor zijn. Je zou de check ook door de PL kunnen laten uitvoeren. Meer ingewikkelde checks, of een 'event' dat een aantal gerelateerde 'events' moet triggeren, is dan weer BLL. De BLL is dus niet zomaar een doorgeefluik.

Waarom trouwens niet VB.Net gebruiken (of C#) in combinatie met .Net Remoting of webservices?

[whoami]

Lorn schreef op 24 september 2004 @ 16:59:
- DAL en BLL, aparte DLLs?
Implementeer je de DAL en BLL ieder in een aparte DLL?

Ja, op die manier kan je dan nl. makkelijk je DAL en BL op verschillende servers plaatsen.

Wat als die twee DLLs nou niet op dezelfde machine komen te staan, hoe maak ik dan binnen de BLL een referentie aan naar de DAL?

In .NET zou ik dit doen dmv remoting of webservices; in VB6 heb ik geen idee.

Wat ik me ook afvraag is of je per business entity een DLL aanmaakt of dat je een algemene DAL/BLL DLL hebt met daarin verschillende classes per business entity.

Meestal een algemene.

- Plaatsing connectionstring
Ik zou nu een connectiestring maken door de gebruiker op te laten geven welke database en SQL login er gebruikt moeten worden. Omdat de presentatielaag zelf geen interactie heeft met de database lijkt dat niet zo heel zinnig. In de meeste voorbeelden zie je dan ook dat de DAL en BLL zelf de connectiestring laden uit een bestand. Opzich geen probleem natuurlijk maar hoe regel je dan de rechten op de SQL server? Ik neem aan dat dit dan niet meer gaat via SQL accounts.

Je kan dit doen dmv integrated windows security als al je clients op windows draaien.

- Wat plaats je waar?
Stel ik heb een tabel met persoonsgevens. Mijn applicatie biedt de mogelijkheid om een persoon toe te voegen. Als eis wordt er gesteld dat een persoon minimaal 16 jaar moet zijn. Als ik het goed heb begrepen gebeurd er ongeveer het volgende bij het toevoegen van een nieuw persoon:

Eigenlijk is de BLL dan niet heel veel meer dan een doorgeefluik. Klopt dat?

Als je simpele of geen Business-logic hebt, kan je dat zo wel beschouwen ja. Indien dit het geval is, moet je je ook gaan afvragen of het dan wel zinnig is om die opsplitsing te maken. In dat geval zou je de DAL en de BL bv tot 1 tier kunnen brengen.

- Connection pooling
Om gebruik te maken van de ADO connection pooling maak je in het begin van je applicatie een connectie aan die je vervolgens weer sluit zonder het connectie object vrij te geven. Hoe gaat dit in een n-Tier omgeving? Laat je dit gebeuren bij het creeeren van de DAL?

Er zijn 2 voorwaarden om gebruik te kunnen maken van connection-pooling:
1) Je sluit je connectie van zodra je ze niet meer nodig hebt:
bv (pseudo-code)

code:

connectie.Open();
connectie.BeginTransactie();

INSERT bla....
UPDATE bla...
UPDATE bla
commit transactie
sluit connectie

2) je connectie-string moet identiek zijn; ttz, voor iedere identieke connection-string wordt er 1 connectie-pool gemaakt. Als je dus gebruik maakt van integrated security, dan gebruikt iedere user dezelfde connectie-string. In dat geval heb je dus 1 connectie-pool.

[whoami]

RedRose schreef op 24 september 2004 @ 17:22:
[...]

De BL en de DAL zouden beide 'stateless' moeten zijn

Dat de DAL stateless kan zijn, daar ben ik mee akkoord.
Echter, een stateless BL heb ik nog nooit gezien/gebruikt. Ik zou niet weten wat het voordeel daar van is; het is imo trouwens alleen maar een nadeel. Waar ga jej e state dan gaan opslaan?

[RedRose]

whoami schreef op 24 september 2004 @ 17:26:
[...]

Dat de DAL stateless kan zijn, daar ben ik mee akkoord.
Echter, een stateless BL heb ik nog nooit gezien/gebruikt. Ik zou niet weten wat het voordeel daar van is; het is imo trouwens alleen maar een nadeel. Waar ga jej e state dan gaan opslaan?

Dat is een beetje het probleem waar ik momenteel mee zit

Met state bedoel ik overigens (denk ik) niet de scope die jij bedoelt. Intern in de BL, zit state, logisch. Ik doelde meer op de communicatie tussen de tiers. Maar ik zit momenteel erg in EfBe's helpfile te spitten en wat ik zei: ik kan dat (nog) helemaal niet goed uitleggen.

[ Voor 2% gewijzigd door RedRose op 24-09-2004 17:36 . Reden: typo's ]

[Tomatoman]

- DAL en BLL, aparte DLLs?
Een DLL is een bestand en heeft als zodanig niets te maken met access layers. De access layers kunnen op talloze manieren worden geïmplementeerd en stuk voor stuk kunnen die implementaties al dan niet gebruik maken van DLL's. Vergeet de DLL's dus voorlopig maar even, die zijn in dit stadium totaal niet relevant. (Er is trouwens ook geen verband tussen DLL's en ADO.)

- Plaatsing connectionstring
Een connection string wordt onder meer gebruikt in combinatie met ADO om databases te benaderen. Een connection string maakt onderdeel uit van de specifieke implementatie van een bepaalde data access methode. De meeste data access methodes kennen het begrip connection string niet eens. Kortom: er is geen enkele relatie tussen het concept van access layers en connection strings.

- Wat plaats je waar?

[...] Eigenlijk is de BLL dan niet heel veel meer dan een doorgeefluik. Klopt dat?

Eenvoudig gezegd: dat klopt. Er zijn echter ook scenario's denkbaar waarbij de BLL veel meer doet. De BLL zou bijvoorbeeld bij iedere bewerking kunnen controleren of de client wel de noodzakelijke rechten heeft om de bewerking uit te voeren. De BLL zou ook kunnen filteren welke data de client ontvangt van de server (misschien moeten bepaalde gegevens worden verborgen voor 'normale' gebruikers). De BLL kan veel meer doen dan als een intelligent doorgeefluik fungeren. In ieder geval zorgt de BLL voor een bepaalde mate van gegevensvalidatie.

- Connection pooling

Om gebruik te maken van de ADO connection pooling maak je in het begin van je applicatie een connectie aan die je vervolgens weer sluit zonder het connectie object vrij te geven. Hoe gaat dit in een n-Tier omgeving? Laat je dit gebeuren bij het creeeren van de DAL?

Deze vraag staat los van de vraag of je een aparte DAL en BLL gebruikt. De vraag zou precies hetzelfde zijn als je een multi-tier applicatie maakt zonder strikte scheiding tussen DAL en BLL. Je kunt zelf het scenario kiezen dat het beste aansluit bij jouw specifieke situatie. Zonder die te kennen valt op jouw vraag geen sluitend antwoord te geven.

[whoami]

tomatoman schreef op 24 september 2004 @ 17:41:
- DAL en BLL, aparte DLLs?
Een DLL is een bestand en heeft als zodanig niets te maken met access layers. De access layers kunnen op talloze manieren worden geïmplementeerd en stuk voor stuk kunnen die implementaties al dan niet gebruik maken van DLL's. Vergeet de DLL's dus voorlopig maar even, die zijn in dit stadium totaal niet relevant. (Er is trouwens ook geen verband tussen DLL's en ADO.)

Het gaat er wel om dat je je BL en je DAL in sommige gevallen fysisch van elkaar gescheiden wilt houden (op verschillende machines). In dit geval moeten ze dus in verschillende files zitten.

- Plaatsing connectionstring
Een connection string wordt onder meer gebruikt in combinatie met ADO om databases te benaderen. Een connection string maakt onderdeel uit van de specifieke implementatie van een bepaalde data access methode. De meeste data access methodes kennen het begrip connection string niet eens. Kortom: er is geen enkele relatie tussen het concept van access layers en connection strings.

Het gaat hier in dit concrete voorbeeld ook wel over SQL Server/ADO/VB; de TS heeft er waarschijnlijk niet veel aan als we te abstract bezig zijn. Het is beter dat we toespitsen op zijn situatie.

[Tomatoman]

whoami schreef op 24 september 2004 @ 17:58:
Het gaat hier in dit concrete voorbeeld ook wel over SQL Server/ADO/VB; de TS heeft er waarschijnlijk niet veel aan als we te abstract bezig zijn. Het is beter dat we toespitsen op zijn situatie.

In dat geval een antwoord toegespitst op de specifieke situatie . Stel dat je ooit besluit dat de database op een andere server moet gaan draaien, dan moet natuurlijk de connection string worden aangepast. In principe heeft het veranderen van de database wel invloed op de DAL (want de data komen nu ergens anders vandaan), maar niet op de BLL (de bestaande business rules zijn nog steeds van toepassing).

Als de connection string in de BLL zou worden bewaard, zou een verandering aan de kant van de DAL - in dit geval dat de database op een andere server wordt geïnstalleerd - ervoor zorgen dat de connection string in de BLL moest worden veranderd. Dat is onlogisch, omdat er dan een geen volledige scheiding meer is tussen DAL en BLL. Als de connection string daarentegen in de DAL wordt bewaard, heeft een verandering in de database geen invloed op de BLL, precies zoals het hoort. Conclusie: de connection string moet in de DAL worden bewaard.

Een nogal uitgebreid antwoord op een vrij eenvoudige vraag. Reden: met deze redenatie kun je heel vaak bepalen of iets in de DAL of juist in de BLL moet worden geïmplementeerd. Helaas blijven er ook flink wat twijfelgevallen over.

[whoami]

Bewaar je connection-string ergens in een 'beveiligde' config-file, en laat je DAL die config-file accessen om de connectie-string te weten. (cfr web.config in ASP.NET)

[Verwijderd]

In VB6 N-tier omgeving was het gebruikelijk (want tegenwoordig gebruik je natuurlijk eigenlijk geen VB6 meer) om je componenten in COM+ te hangen.
De COM+ applicatie kun je vervolgens laten draaien onder een spaciaal service accont dat je hiervoor aanmaakt. Dit NT account geef je rechten om met integrated security SQL server te banaderen.


Dit heeft oa als voordeel dat je in je connectiestring geen username en password hoeft op te nemen. je kunt deze dan veilig ergens in de registry zetten ofzo


Het scheiden van je DAL en BLL componenten over verschillende machines is echt onzinnig. Dit geeft alleen maar extra overhead. Veer meer winst behaal je door je database zelf op een aparte machine te zetten. Als je nog meer wilt load balancen dan kun je beter een NLB gebruiken om meerdere applicatie servers in te zetten. Op iedere applicatieserver draaien vervolgens zowel je BLL als je DAL componenten eventueel je website (IIS) als je een webclient gebruikt. Voor een nette opdeling kun je ze natuurlijk wel in lossen DLLs plaatsen, dit heeft vooral voordelen als je met meerdere mensen gelijk aan het project werkt.


In de BLL zitten juist je buisiness rules, dit is dus meer dan zomaar een doorgeefluik. De DAL is meer een doorgeefluik, maar deze dient om de BLL code schoon te houden van gedoe met de database en ADO enzo. De BLL blijft dan netjes en schoon. Je maakt dan per business entity een class. Als je veel classes hebt dan is het verstandig ze op een logische wijze te groeperen in lossen DLL's. DIt weer vooral om makkelijk met een team te kunnen werken.


Als je je componenten in COM+ hangt, en altijd onder het zelfde account naar de database gaat wordt connection-pooling eigenlijk automatisch geregeld. Je moet dan wel steeds netjes je connectie sluiten en vervolgens de connectiel property van je recordset op Nothing zetten. Op dat moment wordt de connectie niet echt gesloten maar gaat in de pool voor het geval iemand anders later precies zo'n connectie wil hebben. Doordat je integrated security gebruikt zijn alle connecties hetzelfde en kunnen dus optimaal worden hergebruikt.


Over state in N-tier applicaties kan ik kort zijn, die hoort natuurlijk in de database. Dat is ook het model dat COM+ hanteerd.

[Lorn]

Wow, dat zijn aardig wat replies. Iedereen bedankt! Er staat zeker een hoop nuttige informatie, heb er veel aan gehad. Het roept alleen ook weer wat nieuwe vragen op.

Er werd door meerdere mensen opgemerkt dat VB.NET beter geschikt zou zijn voor deze taak. Ongeacht of dat dat waar is of niet is het helaas geen optie. We hebben hier alleen VB6 en het ziet er niet naaruit dat op korte termijn .NET wordt aangeschaft. Ben dus 'veroordeeld' tot het werken met VB6.

Het is me duidelijk dat de SQL server geconfigureerd moet worden om met Windows security samen te werken. Dat lost dan ook in een keer mijn probleem op met connection pooling. Da's natuurlijk heel mooi. Verder is me iets duidelijker geworden hoe te bepalen wat in de DAL en wat in de BLL thuis hoort.

Ik heb nu alleen weer een ander probleem waar ik mee worstel. Stel ik heb nog steeds die personen tabel en ik wil de inhoud hiervan laten zien aan de gebruiker. De applicatie toont mooi een lijst met alle aanwezige personen en zodra iemand wordt geselecteerd dan toont de applicatie detail informatie. De oproep voor de informatie uit de SQL gaat dus via de BLL naar de DAL en dan via dezelfde weg weer naar mijn applicatie.
Is het nou slimmer om alle info in een keer op te vragen of is het beter om de info op te vragen als het nodig is? Ik kan me voorstellen dat het voordeel om alles in 1 keer op te halen is dat er minder oproepen nodig zijn tussen de verschillende lagen. Haal je echter de details pas op zodra een persoon is geselecteerd dan ga je niet onnodige data over je netwerk versturen.
Voor beide situaties lijkt me dus wel wat te zeggen. Wat heeft in de praktijk nou de voorkeur?

RedRose schreef op 24 september 2004 @ 17:31:
[...]
Maar ik zit momenteel erg in EfBe's helpfile te spitten en wat ik zei: ik kan dat (nog) helemaal niet goed uitleggen.

Die helpfile waar je het over hebt, gaat die over n-Tier applicaties? Is het een digitaal bestand? Zou ik dan misschieen een copy kunnen krijgen

[ Voor 11% gewijzigd door Lorn op 27-09-2004 09:19 ]

[whoami]

Lorn schreef op 27 september 2004 @ 09:14:

Is het nou slimmer om alle info in een keer op te vragen of is het beter om de info op te vragen als het nodig is? Ik kan me voorstellen dat het voordeel om alles in 1 keer op te halen is dat er minder oproepen nodig zijn tussen de verschillende lagen. Haal je echter de details pas op zodra een persoon is geselecteerd dan ga je niet onnodige data over je netwerk versturen.

Data ophalen als het nodig is. Het lijkt op papier natuurlijk mooi dat je je lijst van personen allemaal direct kan gaan opladen en tonen.
Echter, dat is in de praktijk niet werkbaar. Als je 100 aparte select's moet doen om die informatie op te halen, gaat het gewoon veel te traag gaan, wil je nog een responsief programma.
Je moet gewoon die lijst tonen, en als er dan een item geselecteerd wordt, dat item gaan ophalen.
Op die manier ben je er ook zeker van dat je op dat moment de meest recente informatie uit de databank hebt ivm dat record. Doe je dat niet, dan heb je kans dat jij met een oude versie van dat record in je memory zit.

[Lorn]

whoami schreef op 27 september 2004 @ 09:23:
[...]

Data ophalen als het nodig is. Het lijkt op papier natuurlijk mooi dat je je lijst van personen allemaal direct kan gaan opladen en tonen.
Echter, dat is in de praktijk niet werkbaar. Als je 100 aparte select's moet doen om die informatie op te halen, gaat het gewoon veel te traag gaan, wil je nog een responsief programma.
Je moet gewoon die lijst tonen, en als er dan een item geselecteerd wordt, dat item gaan ophalen.
Op die manier ben je er ook zeker van dat je op dat moment de meest recente informatie uit de databank hebt ivm dat record. Doe je dat niet, dan heb je kans dat jij met een oude versie van dat record in je memory zit.

Is misschien met het oog op locking ook wel beter.

Zat net te denken over op welke manier de informatie tussen de verschillende lagen te sturen. Als ik data ga ophalen lijkt me het handigst om dit met disconnected recordsets te doen. Maar wat als ik nou een nieuw persoon wil toevoegen? Ook een disconnected recordset, een UDT (en waar definieer ik die dan) of via parameters naar een routine in mijn BLL?

Eigenlijk komt er stiekum nog best een hoop bij kijken... meer dan dat ik me misschien in eerste instantie wel heb gerealiseerd.

[Lorn]

OK, hoe meer ik lees hoe meer ik er van overtuigd raak dat ik niks weet. Ik denk niet dat ik er zonder boek uit ga komen, daarvoor mis ik gewoon te veel kennis. Zijn er mensen die een bepaald boek kunnen adviseren? Ik heb net al gezocht op Amazon.com maar zie door de bomen het bos niet meer. Ik zit te denken aan een (of meerdere )van de volgende boeken:
- Programming Distributed Applications with COM+ and Microsoft Visual Basic 6.0 by Tom Pattison
- Building N-Tier Applications with COM and Visual Basic 6.0 by Ash Rofail
- Scot Hillier's COM+ Programming with Visual Basic by Scott Hillier
- Visual Basic and COM+ Programming by Example by Peishu Li

[EfBe]

Wellicht wat minder tijd kostend: http://www.sd.nl/software/llblgendocs/ntier.htm , een artikeltje uit de oude llblgen docs over ntier development en hoe je er tegenaan kunt kijken. Helpt je niet direct met code snippets maar wel met wat de visie achter n-tier development is. Daarmee kun je dan bv je design makkelijker inrichten of beter in documentatie zoeken naar elementen die je nodig hebt. Vergeet niet: n-tier development is een erg algemene vage term. Vraag 10 ontwikkelaars wat er onder verstaan wordt en je krijgt 10 verschillende antwoorden

In de MSDN staan verder een inmense hoeveelheid docs over windows DNA. dat is wat je wilt weten. Ik denk dat je daarmee moet starten alvorens een boek te gaan kopen, want omdat n-tier development zo'n vage term is, loop je het risico een boek te kopen dat helemaal niet geschikt is voor jouw situatie.

[ Voor 22% gewijzigd door EfBe op 27-09-2004 11:20 ]

[Lorn]

EfBe schreef op 27 september 2004 @ 11:18:
Wellicht wat minder tijd kostend: http://www.sd.nl/software/llblgendocs/ntier.htm , een artikeltje uit de oude llblgen docs over ntier development en hoe je er tegenaan kunt kijken. Helpt je niet direct met code snippets maar wel met wat de visie achter n-tier development is. Daarmee kun je dan bv je design makkelijker inrichten of beter in documentatie zoeken naar elementen die je nodig hebt. Vergeet niet: n-tier development is een erg algemene vage term. Vraag 10 ontwikkelaars wat er onder verstaan wordt en je krijgt 10 verschillende antwoorden

In de MSDN staan verder een inmense hoeveelheid docs over windows DNA. dat is wat je wilt weten. Ik denk dat je daarmee moet starten alvorens een boek te gaan kopen, want omdat n-tier development zo'n vage term is, loop je het risico een boek te kopen dat helemaal niet geschikt is voor jouw situatie.

Ik heb het document gelezen, zeer helder. Denk dat ik de algemene theorie achter n-Tier applicaties wel onder de knie begin te krijgen. De voordelen zijn me in ieder geval duidelijk. Waar ik echter mee blijf zitten zijn vragen over de implementatie. Zo kom je technieken tegen als interfaces, COM+, MTS, DTC, DNA... en nog veel meer. Mijn oren beginnen al te klapperen bij COM+, een techniek die toch wel basiskennis lijkt te zijn. Ik denk dat ik daar zowieso een boek voor nodig ga hebben.

Ik ga zo dadelijk eens kijken wat MSDN te bieden heeft aan DNA documentatie... ben benieuwd of het wat kan ophelderen

[EfBe]

Lorn schreef op 27 september 2004 @ 12:17:
Ik heb het document gelezen, zeer helder. Denk dat ik de algemene theorie achter n-Tier applicaties wel onder de knie begin te krijgen. De voordelen zijn me in ieder geval duidelijk. Waar ik echter mee blijf zitten zijn vragen over de implementatie. Zo kom je technieken tegen als interfaces, COM+, MTS, DTC, DNA... en nog veel meer. Mijn oren beginnen al te klapperen bij COM+, een techniek die toch wel basiskennis lijkt te zijn. Ik denk dat ik daar zowieso een boek voor nodig ga hebben.

MTS: microsoft transaction server, een service van windows NT 4, waarin je COM objects kon hangen die dan in een transaction konden draaien, en die transaction kon meerdere applicaties beslaan. Dus bv jij start vanuit je webpage een MTS transaction, die bevat dan de calls die je doet in die asp page, maar ook de calls die gedaan worden in de COM components die aangeroepen worden in die page, en bv ook de calls die gedaan worden in SqlServer die aangeroepen word in het com component. Dit werd gecoordineerd (nog steeds overigens) door de MS DTC, de Distributed Transaction Coordinator
COM+: opvolger van MTS, zit in Windows 2000, XP en Windows 2003 (XP en windows 2003 hebben een nieuwere versie van COM+ dan windows 2000, maar dat is niet zo belangrijk). COM+ heet ook wel component services. Blijft hetzelfde idee: een service die components beheert en executeert. Deze service heet nog steeds de DTC.
DNA: de naam voor n-tier design/architecture. Meer een buzzword.

Het basisbegrip is 'COM'. COM is de benaming voor binary component model, oftewel een systeem waarmee je binary components gebruikt ipv een library met functies. Een binary component is vergelijkbaar met een VB class met functies. Je kunt meerdere binary components, of 'COM components' in een dll hebben. Ieder COM component heeft een interface, de set met functies die de component aanbiedt. Veelal heeft een COM component meerdere interfaces, bv IFoo_v1 en IFoo_v2, 2 versies van dezelfde interface. Ieder component heeft een CLSID, een uniek ID die ervoor zorgt dat windows weet waar hij een bepaald object kan vinden. Stel dat jij in je VB programma een bepaald ActiveX control gebruikt. Dat is een COM component met een bepaalde set interfaces. Jij gebruikt dus in feite component X met CLSID abc. Wanneer jouw programma runt, bevat je programma een stukje routine die een instance opvraagt van de component met CLSID abc. Dit wordt gedaan door een service in windows, de SCM. Deze krijgt van VB de CLSID en kijkt in de registry in welke dll de component met dat CLSID is te vinden. Dan wordt die DLL geladen en die DLL wordt gevraagd een object te creeeren van de component met CLSID abc. Jij krijgt dan een referentie terug naar die instance.

Een CLSID is een guid, een 128 bit uniek nummer die in 32characters hexadecimaal wordt gepresenteerd, die vele lange vage nummers in de registry. Om vriendelijkere namen te gebruiken is er ook een PROGID, zoals Projectnaam.Classname. Deze wordt gebruikt in bv asp, wanneer je Server.CreateObject() aanroept.

Het verhaal is erg complex onder water, maar daarmee hoef je je niet te vermoeien, als je met VB6 aan de slag gaat is dit voldoende. Wat je dus in VB6 maakt is een ActiveX library, en iedere class in je project wordt een COM component.

COM components zijn shareable door meerdere applicaties. Dit houdt dus in dat je 1 library kunt maken en deze in je webapplicatie kunt gebruiken, maar ook tegelijkertijd in een win32 desktop applicatie. Dat is het voordeel van COM: het delen van bestaande code. Je kunt je COM components ook in COM+/MTS hangen en ze dan deel laten uitmaken van een transaction die meerdere COM components beslaat (hiervoor moet je wel wat extra handelingen verrichten, maar daar is veel documentatie over te vinden in de MSDN).

gewoon stapje voor stapje de handel doornemen, het is allemaal niet zo moeilijk, maar wel erg veel en veel heb je gewoon niets mee te maken als je bv VB of Delphi gebruikt.

Overigens, als je de kans krijgt, kijk eens naar .NET. .NET versimpelt het gebeuren grotendeels en als je toch veel tijd moet investeren in een nieuwe techniek zou ik het in .NET doen, niet in VB + COM+ + ASP.

[Lorn]

EfBe schreef op 27 september 2004 @ 12:45:
[...]

Interessant, duidelijk verhaal

Thanks! Dat was een duidelijk stuk, vooral de eerste paragraaf was verhelderend. Ik heb trouwens gezocht op MSDN naar informatie over DNA is toch lastig te vinden. Daarnaast is bijna alles geschreven voor .NET wat het nog iets lastiger maakt. Toch hier en daar wel goede informatie gevonden.

Ik moet eerlijk bekennen ondertussen een beetje aan het twijfelen te zijn. Begin me af te vragen of ik daadwerkelijk wel een n-Tier oplossing nodig heb. Stel dat er ooit 150 gebruikers tegelijkertijd gebruik willen maken van het systeem dan zou dat al érg veel zijn. Voor de schaalbaarheid zou ik 't dus niet hoeven te doen denk ik.

De reden waarom ik aan een n-Tier oplossing denk is omdat de scheiding tussen presentatielaag en business logic / data access me erg aanspreekt. Verder zou het makkelijk zijn als in de toekomst er naast een Win32 client er ook een webclient mogelijk zou zijn. Als de presentatielaag dan al gescheiden is dan is dat allemaal maar een groot voordeel.

Ik begin me af te vragen of dat het wel genoeg reden is om te beginnen aan een n-Tier oplossing. Het is een afweging die ik dus nog moet maken.

[whoami]

Lorn schreef op 27 september 2004 @ 13:33:
[...]

Ik begin me af te vragen of dat het wel genoeg reden is om te beginnen aan een n-Tier oplossing. Het is een afweging die ik dus nog moet maken.

Als er ruimte voor is (qua tijd en budget) en ondersteuning van iemand die al eens zo'n project gedaan heeft, zou ik het zeker doen. Het zou een mooi leerproject zijn.

Indien je Business Logic niet te complex is, zou je kunnen overwegen om de DAL en de BL in 1 tier te schrijven.
Dit zou het project wat kunnen vereenvoudigen, en aangezien je BL dan toch niet te ingewikkeld is, kan je nog een goed overzicht behouden.

[Lorn]

whoami schreef op 27 september 2004 @ 14:19:
[...]


Als er ruimte voor is (qua tijd en budget) en ondersteuning van iemand die al eens zo'n project gedaan heeft, zou ik het zeker doen. Het zou een mooi leerproject zijn.

Indien je Business Logic niet te complex is, zou je kunnen overwegen om de DAL en de BL in 1 tier te schrijven.
Dit zou het project wat kunnen vereenvoudigen, en aangezien je BL dan toch niet te ingewikkeld is, kan je nog een goed overzicht behouden.

Tijd en budget is er misschien wel. Als er goede argumenten zijn om een n-Tier oplossing te implementeren dan zal er zeker serieus naar gekeken worden. Dat is denk ik niet het probleem. Ondersteuning is een ander verhaal. We hebben maar een vrij klein team en niemand heeft ervaring met zoiets. Nou kom je met internet wel een eind maar is natuurlijk niet echt handig.

Ik verwacht dat de business logic vrij beperkt gaat zijn. Ik denk dat het dus wel samen in 1 tier kan met de DAL.

Ben het trouwens helemaal met je eens dat het een mooi leerproject zou zijn. Ben wel erg geinteresseerd om het uit te proberen. Mocht het nou op mijn werk niet doorgaan dan is het misschien iets om eens in mijn vrije tijd te gaan doen. Loop al een tijd met het idee om een syteem te maken om m'n DVD collectie in bij te houden. Kan dan mooi het nuttige met het aangename combineren

[Verwijderd]

Zoals je uit de verschillende racties merkt komt er een hoop kennis van de omgeving bij kijken en maakt het je project vele malen complexer.

Ik denk dat je je naast hoe je een n-tier omgeving moet opzetten ook de vraag moet stellen waarom je dat eigenlijk wilt.

Mogelijke redenen kunnen zijn
* Veel concurrent gebruikers (>100)
* Veel complexe buisenesrules
* Multi channel, Meerdere kanalen om dezelfde functionaliteiet aan te roepen (Web, Windows client, SMS, E-mail, etc.)
* Veel flixibiliteit geeist door bv korte time to market

Begrijp me niet verkeerd, ik ben absoluut een voorstander van n-tier en service georienteerde architecturen, maar het moet wel een doel hebben.

Verder geef je aan dat je het met VB6.0 moet doen omdat je geen .NET hebt. Ik denk eigenlijk dat als je project niet belangrijk genoeg is om moderne tools aan te schaffen dat je ook geen echte case hebt voor zo'n zware architectuur. Andersom, als het belangrijk genoeg is voor een zware architectuur dan zijn die tools (.NET) ook wel te betalen, dat verdien je op de lange termijn nl heel snel terug.