[VB+DCOM+SQL Server] DCOM vragen

[ParaNoiMia]

Ik heb een VB6 applicatie die nu nog communiceert met een Oracle database middels OLEDB en de Oracle client.

Deze applicatie moet gaan draaien met een SQL Server database (op zich geen probleem).

Echter, de klant stelt als eis dat het via DCOM moet lopen
(3-tier).

Ik ben al een paar uur bezig met zoeken en lezen en wat ik ervan begrijp, is dat je in VB een DLL gaat maken, die aan de serverkant geinstalleerd wordt en je vanuit VB gebruikt.

Ik heb dit voorbeeld bekeken, waarin in de DLL oa een sql statement wordt uitgevoerd.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q186342

Nu is de applicatie die ik over ga zetten dusdanig van omvang, dat het mij niet logisch lijkt al de SQL statements over te gaan zetten in dat DLL object.

En ik vraag me af of het wel nodig is. Kan je dat DCOM component ook bv gebruiken om alleen je connectie richting database te maken ? Of zijn er andere dingen verplicht ? Ik heb ook voorbeelden gezien waarbij allerlei businessrules in dat DCOM object geprogrammeerd zitten en andere validaties.

Zijn daar richtlijnen voor ? Iemand die een _duidelijke_ site weet over dit onderwerp ? Wat voor vragen moet ik de klant stellen over het gebruik van DCOM ? Wat voor een rol speelt MTS in dit verhaal ?

[LordLarry]

Dit heeft niet direct wat met VB te maken.

In een 3-tier huist veel meer alleen een laag ertussn omdat het moet van de klant, maar die voor de rest niets doet.

Wat jij nu hebt gemaakt met VB en OLE-DB is een Client/Server model. De business logica zitten in de client en je hebt 2 lagen. Een 3-tier heeft er 3. De business logica wordt uit de client gehaald en in een aparte laag gezet. Dat is een beetje erg plat wat een 3-tier is. Wat overgens niet hoeft te betekenen dat het ook physiek 3 verschillende dingen zijn. Als ze maar in de code strikt geschijden zijn. Dat heeft als voordeel dat je de ene laag door een andere 'versie' kan vervangen en zo zonder de andere code aan te passen een andere DB kan gebruiken of een andere client (Web, Delphi, PDA).

DCOM past hier in omdat deze je de mogelijkheid geeft om objecten van buiten af te benaderen. De D in DCOM zorgt er ook voor dat dat op een andere computer zou kunnen zijn.

Je VB app (client) gaat communiceren via DCOM met COM(+) Objecten mogelijk zelfs op een andere computer. Elk object in jullie applicatie zoals Klant wordt dus een COM Object. De client stuurd dus NOOIT sql naar de midden laag. De client vraagt alleen aan het object Klant: Mag ik je naam hebben. Het DCOM Object Klant voert dan pas een query uit via OLE-DB om de gegevens op te halen (liever cachen enzo).

Het ontwikkelen van een 3-tier is geen kattepis, dus ik zou er niet te makkelijk over denken.

[Verwijderd]

DCOM heeft er niet zoveel mee te maken, dat is meer de methodiek die je moet gebruiken om laag n met laag n-1 en laag n+1 te laten communiceren.

Zoek op windows DNA op de microsoft developer site msdn.microsoft.com. 'DNA' is de naam van ms voor 3/n-tier applicatiestructuur.

[Verwijderd]

Hier kan je bijvoorbeeld een stukje over lezen: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndna/html/windnadesign_intro.asp

Verder is dit mogelijk een interessant boek: http://www.developerfusion.com/show/88/9/

En hier kun je wat terug vinden over de theorie achter Component Based Development binnen het MS Windows DNA platform: http://www.cbdiforum.com/public/sigs/cbddna/cbd_win_dna_env.php3 (link naar .zip van PDF links bovenaan)

Over dit onderwerp is erg veel te vertellen en te weten, dus vat het niet te licht op.

Grofweg komt het op het volgende idee neer.

Windows DNA

Verdeel een applicatie in de volgende lagen:

Data
Hier komt de data voor de applicatie vandaan. In de meeste gevallen bestreft het een database maar het kan ook gaan om meerdere databases, directory services of message queues.

Middle Logic
In deze laag wordt de data benaderd, gewijzid aangevuld of verwijderd op basis van Business Rules.

Je Business Rules zijn feitelijk een set regels hoe jouw applicatie zich moet gedragen. Denk aan een ticketreserveersysteem (standaard MS voorbeeld overigens ). Daarin kan je een vlucht op een bepaalde datum zoeken, en dan een ticket voor bestellen, maar natuurlijk alleen als er plaatsen beschikbaar zijn, en de klant ook werkelijk betaald.

De Middle Logic zelf kan soms verder opgedeeld worden in sub-lagen, waarin bijv. onderscheid wordt gemaakt tussen data-access logic, business rules en client communication logic. In dergelijke gevallen spreek je van een n-tier systeem.

Binnen het Windows DNA model wordt deze laag geimplementeerd door COM componenten, die je kunt maken met bijv. Visual Basic, Delphi of Visual C++.

User Interface
Dit is het deel wat een mens gebruikt om de applicatie te besturen. Dit kunnen bijv. ASP pagina's zijn, maar ook een in VB geschreven interface. Deze laag communiceerd met de Middle Logic laag.

Als de client op de server staat zoals met ASP vindt de communicatie plaats op basis van COM, zo niet (zoals bij een VB client die op een aantal client computers draait) dan wordt er met D(istributed)COM gecommuniceerd.

Rol MTS / COM+
Windows DNA kan zowel op het WinNT als het Win2000 platform gedraaid worden. Op Windows NT zal je vaak gebruik maken van Microsoft Transaction Server (MTS, onderdeel van Option Pack 4), bij Win2000 maak je gebruik van COM+ (onderdeel van het OS). MTS / COM+ geven je een manier om je COM componenten te beheersen (stoppen, starten, monitoren) en bieden bovendien een aantal extra services zoals het inbouwen van transactionaliteit in COM componenten. COM+ is daarbij wat uitgebreider dan MTS.

Ik hoop dat het zo wat duidelijker is. Veel succes