Collections mit COM

[Specialwork]

Hallo Zusammen,

Ich habe eine Datenbank, einen COM+ Server (Serverschicht), einen COM+ Business Layer(Objektschicht) und eine Client Anwendung.

Der Server übernimmt die Aufgabe, Daten von/in die Datebank zu schreiben bzw. zu lesen. Die Objektschicht hat die Aufgabe die gelesenen Daten zu verifizieren bzw, plausibilisieren und in Form einer Collection dem Client zur Verfügung zu stellen bzw. die vom Client erstellten Collections zur Speicherung an die Serverschicht zu übergeben.

Meine Frage ist: Wie stelle ich es in Delphi am Besten an, die von der Serverschicht übermittelten ADO Recordsets in Collections zu konvertieren ?

Beispiel.: Der Client fordert eine Übersicht aller Kunden an. Nun möchte ich eine Collection haben, die z.B. TCustomers heißt und aus einzelnen TCustomerItem(s) besteht. Jedes TCustomerItem enthält die gleichen Properties wie z.B. Plz, Strasse, Name, Nachname, usw.

Frage: Wie würdet Ihr das entsprechende Interface dazu gestalten !?

Gruß, Tom

[sakura]

Hoho, jetzt wirds lustig ;-) Gib mir mal ein wenig Zeit, ich muss mal schauen, ob ich schnell ein Beispiel zusammen bekomme ;-)

...:cat:...

[sakura]

Also, ich mache es jetzt mal kurz. Dein Collection-Interface muss das Windows-Interface IEnumVariant unterstützen. Im Type-Library Editor musst Du für das Collection-Interface folgende Read-Only-Properties hinzfügen:

• _NewEnum (beachte den führenden Underscore), ID auf -4, Type auf IUnknown *
• Items (wird die Standard-Eigenschaft); ID auf 0; Type auf entweder IDispatch oder den Typen des Collection-Items
• Count; ID ist egal; Type auf long

So, soviel zu den Vorbereitungen.
Die Interface-Klasse der Collection-List muss erweitert werden. Im gelieferten Beispiel wird aus

Delphi-Quellcode:

  TCollectionList = class(TASPMTSObject, ICollectionList)

einfach

Delphi-Quellcode:

  TCollectionList = class(TBaseCollectionList, ICollectionList, IEnumVariant)

TBaseCollectionList kommt aus der mitgelieferten Unit uBaseCollection.

Das Interface des Collection-Item wird in der Type-Library um die Eigenschaft Key erweitert, Type BSTR (WideString), ID auf 0 (Standardeigenschaft; ist optional, aber sinnvoll).
Die Interface-Klasse des Collection-Item muss auch erweitert werden. Im gelieferten Beispiel wird aus

Delphi-Quellcode:

  TCollectionItem = class(TASPMTSObject, ICollectionItem)

einfach

Delphi-Quellcode:

  TCollectionItem = class(TASPMTSObject, ICollectionItem, IBaseCollectionItem)

Das Interface IBaseCollectionItem kommt auch aus der mitgelieferten Unit uBaseCollection.


Die Klasse TBaseCollectionList
In dieser Klasse geschieht das eigentliche der Collection-Arbeit. Die eigentlichen Funktionen des Interfaces IEnumVariant werden hier gefüllt. Collections müssen, wenn diese durchlaufen werden sich selbst klonen, aber mit dem gleichen Daten wie das Original arbeiten. Dadurch werden diese thread-safe. Die mitgelieferte Basisklasse TBaseCollectionList tut genau das. Ich setze die Unit (unter steten Erweiterungen) seit Feb. 2000 ein. Inzwischen ist die Unit mehrere hundert Male erfolgreich implementiert. Ich hoffe es funktioniert auch bei Dir ohne Probleme. Einfach anschauen und testen.

Eine kleine Bitte

Wenn jemand Verbesserungen oder Vorschläge hat, sendet diese bitte an mich.

Jetzt das Beispiel und viel Erfolg ;-) Bedenke, daß das Beispiel mit Delphi 7 erstellt ist und daher die Unit Variants benötigt. Wenn Dein Compiler älter ist (ich glaube bis v5) einfach die Unit aus der Uses-Klausel entfernen, die wurde erst später durch Borland eingeführt.

...:cat:...

[sakura]

P.S. Ich hoffe es ist kein Fehler im Server-Beispiel. Ich habe gerade keine Möglichkeit die Collection zu testen :wall: :mrgreen:

...:cat:...

[Specialwork]

Hallo Sakura,

Zunächst einmal recht herzlichen Dank für Deine prompte Unterstützung.

Ich denke, Du hast verstanden worum es mir geht und mir gleich das entsprechende Beispiel dazu geliefert. Find ich echt lobenswert !!!

Ich werde mir das Beispiel mal genauer anschauen und ein paar Tests damit durchführen.

Gruß, Tom

[sakura]

Ich musste es gerade noch einmal hochladen, da mir ein Fehler unterlaufen war :oops:

...:cat:...

[Specialwork]

Hallo Sakura,

Danke nochmals, das ist genau das was ich brauche.

Es scheint alles wunderbar zu funktionieren. Wie bereits erwähnt werde ich die DLL mal etwas genauer testen.

Hast Du schon ähnliche Erfahrungen im Real-Life-Modus sammeln können !? Mich interessieren vor allem Daten über Geschwindigkeit und Zuverlässigkeit, die mann mit diesem Konzept erzielt. Meine Erfahrungen mit diesem Konzept beruhen sich lediglich auf VC++. Man munkelt ja darüber, das VC++ in jedem Falle immer etwas schneller ist als Delphi.

PS: Nein ..., ich will keine Diskusion darüber führen, welche Sprache besser ist. Die Beste ist und bleibt Delphi !!!

Gruß, Tom

[sakura]

Zitat:

Zitat von Specialwork

Es scheint alles wunderbar zu funktionieren. Wie bereits erwähnt werde ich die DLL mal etwas genauer testen.

:bounce1:

Zitat:

Zitat von Specialwork

Hast Du schon ähnliche Erfahrungen im Real-Life-Modus sammeln können !?

Tag-täglich. Ich mache das, um meine Lebensbrot zu verdienen. All unsere COM-Server welche im Web eingesetzt werden laufen auf diesem Prinzip.

Zitat:

Zitat von Specialwork

Mich interessieren vor allem Daten über Geschwindigkeit und Zuverlässigkeit, die mann mit diesem Konzept erzielt.

Ich habe ca. 1 1/2 Monate nur in diese doofe Unit investiert und die stets verbessert und angepasst. Sie sollte das Optimum an Geschwindigkeit bieten und ist leicht implementierbar. Wenn Du garantieren kannst, das die Collection nicht im Free-Threaded Modus läuft, kannst Du noch auf die CriticalSection verzichten. Das gibt einen weiteren Geschwindigkeitsvorteil ist aber gefährlich.

Zitat:

Zitat von Specialwork

Meine Erfahrungen mit diesem Konzept beruhen sich lediglich auf VC++. Man munkelt ja darüber, das VC++ in jedem Falle immer etwas schneller ist als Delphi.

Mit C++ (ob MS oder Borland) wirst Du an dieser Stelle keine Geschwindigkeitsvorteile erzielen. Der Grund ist recht einfach. Die COM-Schnittstelle und die damit verbundene VT für die Interfaces sind fest durch MS definiert. Was es den Pascal-Code betrifft, sollte sich auch nicht mehr viel machen lassen. Die Collections arbeiten im Enum-Mode über die Methode Next, greifen also lediglich über den Index auf die Items zu, damit kommen auch keine String-Vergleiche zum Tragen und auch deren Geschwindigkeit ist nebensächlich.

Wenn Dir jemand mit einem Vergleich C++ vs. Delphi kommt, Kopf hoch. Wirkliche Vorteile kann C++ nur im tief mathematischen Bereich erzielen und natürlich in der Treiberprogrammierung ;-)

...:cat:...

[Specialwork]

Hallo Sakura,

Ich versuche schon seit einiger Zeit meine Kollegen davon zu überzeugen, das Delphi oder gar der C++ Builder um einiges wirtschaftlicher arbeitet als die Lösung von Microsoft. Mich korzt es regelrecht an, mit welchen Einschränkungen ich tagtäglich konfrontiert werde.

In dem Glauben, Microsoft hätte einiges an seiner Programmiersprache C++ verbessert, habe ich mir das Visual Studio.Net zugelegt. Jedoch weit gefehlt. Außer ein paar Updates in der MFC ist dort nichts passiert. Will man nun einigermaßen komfortabel mit C++ von Microsoft arbeiten, beruht die Geschichte auf dem .NET Framework also Manageged C++.

Also warum lassen sich meine Kollegen davon nur nicht überzeugen !?

Aber, - Was der Bauer nicht kennt, daß ißt er nicht !

PS.: Du hast ein CopyRight auf die Unit UBaseCollection. Gibt es da einige Regeln von denen ich wissen müsste !?

Gruß Tom

[Specialwork]

Hallo Sakura,

Könntest Du mir noch die Frage mit dem Copyright beantworten !?, dann kann ich hier abschließen. Natürlich kannst Du mir auch per Mail antworten unter [e-mail]

Gruß, Tom