TClientSocket auf Datenmodul

[Sir Rufo]

Zitat von Furtbichler:

Zitat von Sir Rufo:

und warum nicht einfach

Delphi-Quellcode:

Procedure TMyDataModule.DataModuleCreate(Sender : TOBject);
Begin
  MyClientDataset := TClientDataset.Create( Self );
  MyClientDataset..... // Properties setzen
end;

Dann kümmert sich das DataModul selber um die Freigabe

Das widerspricht dem Designtemplate: "Wer's anfordert, gibts wieder frei". Ansonsten haste Recht.

Hmmm, mal überlegen wer denn jetzt wer ist ... IMHO ist hier "wer" ja die Instanz von TMyDataModule.
Wenn ich also der erzeugten Instanz vom ClientDataSet als Owner die Instanz von TMyDataModule mitgebe, so ist das nicht nur möglich, sondern auch noch in jeder Hinsicht richtig.

Somit sehe ich es hier in diesem (speziellen) Fall keinen Widerspruch zum Designtemplate, denn der übergebene Owner ist auch derjenige, der es angefordert hat

[Furtbichler]

Es geht aus dem Code nicht hervor, das MyClientDataset ordentlich freigegeben wird. Um den Code zu verstehen, muss ich in fremden Code nachschauen, wobei sich hier Probleme ergeben:
* Habe ich den Quelltext? (hat nicht jeder)
* Existiert ein Manual? (ja ja, F1)
* Wird da wirklich etwas freigegeben? (hoffen wir mal)
Ich muss also ganz schöne Klimmzüge anstellen, um zu verifizieren, das das Objekt freigegeben wird. => Unnötige Arbeit => schlecht lesbar => schlecht wartbar.

Das sind nicht gerade Argumente für deine Version (aus Sicht der Lesbarkeit).

Von der Orthogonalität der verwendeten Klassen her hast Du natürlich Recht: "Das wird überall in der VCL so gemacht, der Designer machts auch, also mach ich es auch. Und das ist auch gut so". Ein versierter Leser des Codes, der vorher anderen VCL-Code gelesen hat, wird diese implizite (eigentlich: versteckte) Freigabe erkennen. Wir programmieren aber im Idealfall nicht für Gurus.

[Sir Rufo]

Zitat von Furtbichler:

Es geht aus dem Code nicht hervor, das MyClientDataset ordentlich freigegeben wird. Um den Code zu verstehen, muss ich in fremden Code nachschauen, wobei sich hier Probleme ergeben:
* Habe ich den Quelltext? (hat nicht jeder)
* Existiert ein Manual? (ja ja, F1)
* Wird da wirklich etwas freigegeben? (hoffen wir mal)
Ich muss also ganz schöne Klimmzüge anstellen, um zu verifizieren, das das Objekt freigegeben wird. => Unnötige Arbeit => schlecht lesbar => schlecht wartbar.

Eine wesentliche Eigenschaft der Klasse TComponent ist die Owner-Beziehung, die im Wesentlichen u.a. dafür sorgt, dass der Owner einer TComponent-Instanz die Freigabe veranlasst, wenn der Owner freigegeben wird.
Man könnte also fast behaupten, dass ein Großteil der Daseinsberechtigung von TComponent aus diese Owner-Beziehung besteht.
Die Klasse TComponent selbst ist eine der wesentlichen Basis-Komponenten der VCL.

Deiner Argumentation folgend und weitergedacht, dürfte ich auch keine TStrings benutzen, weil ich ja nicht weiß, ob die Strings wirklich gespeichert werden (ich müsste dort auch erst mal den Quelltext sichten, und wenn ich den nicht habe ...)
Eigentlich dürfte ich keine Komponenten verwenden ... alles selber programmieren.

Ein weiteres Kriterium, für die Angabe eines Owners, ist der einfachere Zugriff auf die Komponenten über das Components-Array des Owners.
Dieses funktioniert aber nur, wenn ich den Owner bei der Instanz-Erzeugung mit angebe.
Und wenn ich den Owner angebe, dann habe ich - as designed - die Verantwortung für die Freigabe delegiert, an den Owner.

Wer dieses dann im Code nicht versteht, der sollte sich auch den Gefallen tun und den Editor ganz schnell wieder schließen, denn es fehlen die existentiellen Grundlagen für die VCL.

@all: Wenn diese Diskussion hier nervt, dann nur Bescheid geben - wir führen dies dann per PN weiter

[Furtbichler]

Ich sagte ja bereits, das man das so schreiben kann, wenn man unterstellt, das der Leser die VCL und ihre Eigenheiten kennt.

Zitat von Sir Rufo:

Deiner Argumentation folgend und weitergedacht, dürfte ich auch keine TStrings benutzen, weil ich ja nicht weiß, ob die Strings wirklich gespeichert werden

Das ist nicht weitergedacht, sondern um-die-Ecke-gedacht, denn: Die Funktionalität einer Klasse ist etwas anderes als ihre Seiteneffekte. Und die Tatsache, das ein TComponent-Derivat vom Owner freigegeben wird, ist ein nicht im Code dokumentierter Seiteneffekt (ja gut'eh, Seiteneffekte sind vom Wesen her nicht dokumentiert).

Zitat:

...Wer dieses dann im Code nicht versteht, der sollte .. den Editor ganz schnell wieder schließen...

So kann man sich auch aus der Affäre ziehen.

So, wenn man die sinnvollen Argumente mal gegenüberstellt, dann ergibt sich das gleiche Bild wie eben (imho):
Einerseits (ohne Owner) eine bessere Lesbarkeit für Leute, die die VCL nicht in- und auswendig kennen (also mich z.B. ), andererseits eine im Design der VCL verankerte Verwendung (mit Angabe des Owners) mit praktischen Vorteilen.

Hier ist es imho blöd, das man entweder das eine, oder das andere bekommt, aber nicht beides. Obwohl....

Was passiert, wenn ich MyClientDataset freigebe? Sagt es dem Owner nicht: "Schmeiss mich aus deiner Liste raus"?

Dann könnte ich ja den Owner mit angeben und (wenn ich denn unbedingt will) das Objekt trotzdem explizit freigeben. Damit könnte man die Diskussion im Konsens schließen und sich wieder der Programmierung von diesem dusseligen Suchdingsda widmen, das sowieso keiner braucht. Wie hast Du das doch gleich genannt? "Gugl"?

[DeddyH]

Da man Workarounds ja IMO sowieso tunlichst kommentieren sollte kann man ja gleich dazu schreiben, wieso entweder kein Owner angegeben wurde oder keine explizite Freigabe erfolgt und ist somit aus dem Schneider

[Sir Rufo]

Ich sehe eben dieses Freigeben durch den Owner nicht als Seiteneffekt, sondern als Funktionalität - und eben eine Basis-Funktionalität an. Benutzt du keine Formulare, auf denen ein paar visuelle Komponenten platziert sind (TEdit, etc.)?
Wo ist da im Code dokumentiert, dass die überhaupt erzeugt werden, geschweige denn freigegeben?

Natürlich kann man eine Komponente auch wieder explizit freigeben, denn diese meldet ihrem Owner, dass sie sich jetzt mal vom Acker macht ... schön ist es nicht, aber es funktioniert.

Eigentlich gibt man den Owner an, wenn die Lebensdauer der Komponente vom Owner abhängen soll.
Und praktisch ist das in dem Falle auch, weil man sich einen Speicher (Liste) mit den Komponenten und die Freigabe-Orgie am Ende spart.
Das ist somit für faule Programmierer wie mich gemacht worden

Zitat von DeddyH:

Da man Workarounds ja IMO sowieso tunlichst kommentieren sollte kann man ja gleich dazu schreiben, wieso entweder kein Owner angegeben wurde oder keine explizite Freigabe erfolgt und ist somit aus dem Schneider

Ich habe ja schon einen Workaround angegeben, wo am Ende der normale RAD-Ansatz wieder funktioniert - Komponenten-Drauf-Klatschen

[Medium]

Mal eine ganz andere Frage: Soweit ich weiss, arbeiten Sockets (zumindest die Delphi-Dinger) mit Fensterhandles bzw. Messages. Wenn man sowas auf ein DM steckt, kommen dann die Events und alles überhaupt an?

[Jens Hartmann]

Zitat von Medium:

Mal eine ganz andere Frage: Soweit ich weiss, arbeiten Sockets (zumindest die Delphi-Dinger) mit Fensterhandles bzw. Messages. Wenn man sowas auf ein DM steckt, kommen dann die Events und alles überhaupt an?

Ich bin gerade nicht ganz sicher, aber irgendwo habe ich sogar gelesen, das man die Sockets auf ein Datenmodul legen kann. Außerdem hat es bisjetzt mit D2007 ja auch wunderbar funktioniert.

Der Vorteil ist, ich kann von jedem Formular geziehlt auf die TClientSocket zugreifen. Wenn ich diese ins MainForm lege, müsste ich ja mit Querverweisen arbeiten.

Delphi-Quellcode:

uses
  IrgendeineForm;
....

implementation //von Irgendeiner Form

uses
  MainForm;

Beim Datenmodul,kann ich jeweils auf diese zugreifen, kann vor dem Programmstart schon die Serververbindung herstellen.
Daher gesehen, sollte nichts dagegen sprechen.

Ich versteh allerdings nicht, warum ich die Komponenten nicht auf das Datenmodul gelegt bekomme.

Allerdings, nach dem ich die genannten Tips umgesetzt habe, funktioniert es.

Bevor ich einen neuen Thread starte, mal kurz eine andere Frage.
Die Verlegung auf ein Datenmodul ist durch eine zukünftig gewollte Authentifizierung auf dem Server entstanden.
Ich muss also vor dem Start der Anwendung erst prüfen, ob meine Benutzerdaten dem Server bekannt sind. Daher habe ich das ganze auf ein DM verschoben und erstelle dieses vor meinem Anmeldebildschirm. Daher kann ich die Userabfrage direkt auf dem Server machen.

Delphi-Quellcode:

begin
  Application.CreateForm(TDataModule5, DataModule5);
  if Login.Execute then
    begin
      Application.Initialize;
      Application.MainFormOnTaskbar := True;
      Application.CreateForm(TForm4, Form4);
      Application.Run;
    end
  else
    ShowMessage('Fehler bei der Anmeldung, Programm wird beendet!');
end.

Mir stellt sich nun die Frage, ob ich eventuell grundsätzlich eine andere Komponente als die TServer und ClientSocket verwenden sollt. Gibt es irgendeine Komponente die den direkten Uservergleich kann. Oder muss ich das immer selber schreiben.

So mit Protokolldatei etc...

Ich weiß wie das geht, aber wenn ich z.B. beim Start des Servers der TServerSocket(Ähnliche Kompo) die Authentifizierungsdaten zur Verfügung stellen könnte, z.B. UserName = User Password = Password und beim Connect dieses geprüft würde, wäre das für meinen Fall völlig ausreichend und nicht so aufwendig. Gibt es so eine Komponente?

Gruß Jens