Results 1 to 11 of 11

Thread: Ervaringen met n-tier oplossingen

  1. #1

    Ervaringen met n-tier oplossingen

    Hallo,

    Zijn hier toevallig mensen die serieuse ervaringen hebben met n-tier oplossingen? Zoja, wat heb je gebruikt? DCOM, SOAP, Sockets?

    Ik ben momenteel bezig met een DCOM server + clients voor mijn werk, en ik moet zeggen dat dit zeer goed werkt. Heb wel een aantal problemen gehad met de ADOConnectie, maar die is nu gewoon server-wide geworden, alle clients delen dus 1 ADOConnection. Opzich geen probleem.

    Mijn Type Library ziet er als volgt uit:


    zoals je ziet heb ik een aantal Childs welke door middel van een SharedConneciton op de client zijn te benaderen. Zo houd ik de boel een beetje overzichtelijk.

    Verder zit er 1 gewone DataModule in waar dus de ADOConneciton op zit die een MSSQL database gebruikt. Deze module is auto-create en wordt dus door alle Childs + GeneralModule gebruikt.


    Zijn er mensen die ook ervaringen hebben?

  2. #2
    alle clients delen dus 1 ADOConnection
    Ik hoop dat ze dan wel een aparte transactie krijgen? Anders wordt het wel heel verassend als één van de processen een rollback gaat doen. Maar ik denk zelf dat je meer problemen gaat krijgen als je componenten gaat delen tussen je verschillende threads. Wat ging er mis toen iedere client zijn eigen Connection had?
    Marcel

  3. #3
    Alle Childs moesten de ADOConnection gebruiken van de GeneralModule. De GeneralModule wordt altijd gemaakt als er een client verbinding maakt. Heeft een client een Child nodig dan wordt deze ook gemaakt.

    Maar nu moeste de database componenten op de Childs een connection hebben, namelijk de connection op de GeneralModule. Maar ik kon niet achterhalen welke GeneralModule er hoort bij welke Child. Je kon wel gewoon in de Object Inspector de ADOConneciton opgeven, maar dat ging hopeloos mis: allen Childs gebruikte de ADOConnection van de EERSTE GeneralModule (dus de eerste client). Ging de eerste client weg, dan werd zijn GeneralModule ge-destroy-t en hadden alle andere Childs/clients GEEN ADOConnectio meer.

  4. #4
    Klopt, daar kom je niet onderuit om die runtime te vullen. Mijn hoofd datmodule ondersteund een interface waarmee de connectie kan worden opgevraagd. Op die manier kan ieder object kijken of de owner de interface ondersteund en zo ja de connectie aanvragen.
    Marcel

  5. #5
    Zoals je kunt zien in de TLB hierboven weet elke Child precies wat zijn MainDataModule (GeneralModule) is, maar hoe krijg ik dat de ADOConnectio die bij op die GeneralModule zit?

  6. #6
    Ik zit even naar je TLB te staren, maar ik snap hem niet helemaal. Je interfaces hebben een property MainDM, begrijp ik het goed dat de client een datamodule moet/kan zetten?
    Marcel

  7. #7
    Die worden zo gezet:
    Code:
    function TGeneralModule.Get_TableChild: TableModule;
    begin
      Result := FTableRDMFactory.CreateComObject(nil) as ITableModule;
      Result.MainDM := Self;
    end;

  8. #8
    Ik snap het, maar door een datamodule in je interface te zetten geef je je 'gebruiker' (de client) het gevoel dat dat een property is die moet worden ingevuld. Maar ik begrijp dat je dat op de server doet.

    Ik kies zelf altijd voor de volgende opzet: de server heeft maar één remote datamodule, deze fungeert alleen maar als doorgeefluik. Dus op de client wordt een provider opgevraagd, de remote datamodule op de server doet niets anders dan een andere datamodule aanmaken waar deze provider opstaat en deze de betreffende opdracht uit laten voeren. De remote datamodule is ook degene die het connectie component bevat, deze wordt dan door de gewone datamodule opgevraagd.

    Het voordeel van deze aanpak is dat alle DataSnap specifieke zaken in één datamodule zitten en de andere datamodules gewoon werken zoals ze altijd doen.
    Marcel

  9. #9
    Uuhmm, misschien iets voor de volgende keer.

    Maar deze werkt ook zeer goed, en heb momenteel weinig tijd om dat te gaan ombouwen. Tijd is geld.

    De manier waarop ik het nu heb gemaakt vind ik ook zeer prettig werken. Je kunt de verschillende onderdelen mooi opsplitsen, zo hou je overzicht.

    Verder zijn die Childs niet direct te benaderen vanaf een client, alleen met een SharedConnection welke weer aan een DCOMConnection zit.

  10. #10
    Heb je helemaal gelijk in, er is niet één manier waarop het moet gebeuren. Gelukkig niet, dat is nou net het voordeel van Delphi: geen strak keurslijf, maar gewoon zelf kijken wat je de beste oplossing vind.
    Marcel

  11. #11
    Ik wou/wilde dus per client een eigen ADOConnection, maar dat is me dus niet gelukt en heb vanwege tijd gebrek ook maar een ADOConnection genomen die voor de hele server te bereiken is.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 5
    Last Post: 13-Jan-04, 21:16
  2. Optellen met db
    By coja in forum Databases
    Replies: 1
    Last Post: 26-Apr-03, 18:39
  3. problemen met project geopend met GExperts
    By MisterE in forum Algemeen
    Replies: 4
    Last Post: 20-Nov-02, 16:33

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •