MVVM Framework für Delphi

[mkinzler]

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1286877)

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

Genau das lese ich hieraus auch:

Zitat:

the XML processor MUST behave as if it normalized all line breaks in external parsed entities

Das verstehe ich so, daß der Parser alle erlaubten Line-Breaks akzeptieren und sich so verhalten muss, als ob nur LF vorkommen würde. Das heißt doch, daß in der XML alle erlaubten Line-Breaks vorkommen können (auch gemischt), ohne daß der Parser meckert.

Damit kann man dann auch XML-Dateien z.B. unter Windows mit irgendeinem Editor bearbeiten, auch wenn der beim Speichern CR+LF schreibt.

Aber bei dem genannten Problem ging es wohl auch gar nicht um das Lesen der "falschen" Line-Breaks, sondern um das Speichern in Normalform. Das kann man aber laut Stevie ja einstellen.

[vagtler]

Zitat:

Zitat von mkinzler (Beitrag 1286854)

Stevie hat schon den Grund genannt. Aber der Insider hat da natürlich mehr Einblick.

Sogar mehr als die Autoren von XML! [...]

Das ist jetzt aber sehr Off-Topic, oder nicht?

[mkinzler]

Sorry, ich werde in Der Zukunft die Schauze halten!!!!!!

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1286905)

Zitat:

Zitat von mkinzler (Beitrag 1286877)

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

Genau das lese ich hieraus auch:

Zitat:

the XML processor MUST behave as if it normalized all line breaks in external parsed entities

Das verstehe ich so, daß der Parser alle erlaubten Line-Breaks akzeptieren und sich so verhalten muss, als ob nur LF vorkommen würde. Das heißt doch, daß in der XML alle erlaubten Line-Breaks vorkommen können (auch gemischt), ohne daß der Parser meckert.

Damit kann man dann auch XML-Dateien z.B. unter Windows mit irgendeinem Editor bearbeiten, auch wenn der beim Speichern CR+LF schreibt.

Aber bei dem genannten Problem ging es wohl auch gar nicht um das Lesen der "falschen" Line-Breaks, sondern um das Speichern in Normalform. Das kann man aber laut Stevie ja einstellen.

Der Insider sieht eben alles nur von innen heraus. Und da eine XML-Datei intern nur mit dem UNIX-Zeilenumbruch arbeitet, setzt man vor dem eigentlichen Verarbeiten eine Logik, die diese Zeilenumbrüche einfach herausfiltert/umwandelt.

Wenn man sich also als Insider nur mit dem internen Kram beschäftigt (etwas anderes wäre für einen Insider undenkbar), dann sieht man eben nur diese Zeilenumbrüche.

Manchmal macht es eben auch Sinn sich von seinem Platz zu erheben damit man auch erkennt, was sich neben dem Teller noch so abspielt :mrgreen:

[Phoenix]

Leute, bitte. Ihr wisst es doch eigentlich alle besser: Trolle bitte nicht füttern.

Mal zurück zu MVVM und grundsätzlich Strukturierung von Code:

Zitat:

Zitat von Dejan Vu

Wenn ich die gängigen Programmierpattern (OCP, SRP, SOC usw.) stringent umsetzen will, dann führt kein Weg an einem MVVM-ähnlichen Konzept vorbei. Die Frage ist, ob ich das will, oder ob ich nicht doch pragmatisch das nicht ganz umsetze und manchmal ein wenig schludere.

Pragmatisch kann einem hierbei aber auch auf die Füße fallen. Mal ein Beispiel aus der Praxis:


Ein Team von Entwicklern (über die Zeit zwischen 3 und 6 Leute) sollte ein Softwaresystem bauen. Sie wussten es eigentlich schon damals alle besser: SOLID Prinzipien beachten, Unit- und Integration testen. Fremdkomponenten Kapseln vor dem Verwenden damit sie austauschbar bleiben etc.

Weil sie aber schnell fertig werden mussten, wurde das ganze über den Haufen geworfen und es wurde pragmatisch geschludert'. Oder anders/betriebswirtschaftlich formuliert: Es wurden während der Entwicklung technische Schulden aufgehalst, um durch diese Schulden eine schnellere time to market zu erkaufen. Das mag manchmal eine legitime Entscheidung sein.

Das Team war sich dessen schon bewusst, und sie wollten das was dort hingeschludert wurde auch immer später aufräumen (=die Schulden zurückzahlen). Die Business-seite wollte aber keine Schulden zurückzahlen (=Zeit und damit Geld in Aufräumen investieren), sondern neue Features / Produkte haben. Auch die mussten schnell gebaut werden, also wurden zusätzliche technische Schulden angehäuft.

Wie das nunmal in der Wirtschaft so ist: Auf Schulden werden Zinsen verlangt. Bei technischen Schulden machen sich diese Zinsen dadurch bemerkbar, das auf einmal die Wartungsaufwände steigen. Es werden mehr Bugs, die werden schwieriger zu fixen weil man keine gescheite Testabdeckung hat. Weil der Code sehr eng gekoppelt ist werden neue Features sehr teuer, etc.

Nach technischen Schulden kommt irgendwann die Überschuldung. Und dann irgendwann der Bankrott.

Fast-forward: Nur 4 Jahre später war das System an diesem Zeitpunkt angekommen. Die Ergebnisse:
Das Team war von dem Rotzcode den sie fabrizieren mussten so angewiedert, das bis auf einen das gesamte Team nahezu geschlossen die Firma verlassen hat. Das Know-how: Unwiderbringlich verloren. Das Software-System war als Grundstein für viele Projekte der Firma genutzt worden, die auf dieser suboptimalen Platform haben aufsetzen müssen. Die Weiterentwicklung war ohne Entwicklungsteam komplett eingebrochen, was die Projekte die darauf aufgesetzt haben massiv zurückgeworfen hat. Das System ist inzwischen in einem Zustand, das man es nur noch wegwerfen und nicht mehr weiterentwickeln kann.

Kurzum: Zwischen 12 und 21 Personenjahre Entwicklung direkt an dem System, plus weitere unzählige in den Projekten die darauf basierten sind für die Katz. Die Firma hat viele Top-Performer verloren. Den tatsächlichen wirtschaftlichen Schaden auszurechnen traut sich niemand.

Das ganze muss jetzt nochmal neu gebaut werden. Diesmal richtig: Unpragmatisch und SOLIDe. Wartbar. Erweiterbar. Flexibel. Die ganzen Projekte die darauf aufbauen migriert werden.

Hätte man damals den Pragmatismus beiseite gelassen, nicht geschludert und gleich den Overhead den gute Software nun einmal kostet auch in Kauf genommen, wäre es nie dazu gekommen. Ich sehe die Investition in eine gute Architektur, SOLID und Tests inzwischen wie eine Versicherung. Die Police bezahlt man vorher, aber sie sichert einen davor ab, schlechte Software zu produzieren die einen hinterher deutlich mehr, im schlimmsten Fall bis hin zum Totalverlust des Geschäftes kosten kann.

[DeddyH]

[OT]

Zitat:

Zitat von Phoenix (Beitrag 1286937)

Das System ist inzwischen in einem Zustand, das man es nur noch wegwerfen und nicht mehr weiterentwickeln kann.

Das sag ich schon seit Jahren, aber das will ja niemand hören :mrgreen: [/OT]

[stahli]

@Phoenix

Also das Grundanliegen, gute Wartbarkeit (incl. ggf. Tests) zu erreichen, haben hier alle an der Diskussion Beteiligten sicherlich erkannt und vertreten das.

Für mich stellt sich nur die Frage, wie man am leichtesten dieses Ziel erreicht (ich bin schon ein fauler Sack ;-)).

Man kann ja auch (so kam das in den Videos für mich rüber) ein ViewModel als Zwischenschicht einbinden, die quasi das Model 1:1 kapselt und dann wäre der Aufwand vollständig überflüssig.

Wenn das ViewModel zusätzlich bestimmte GUI-Statusinformationen oder GUI-Logiken bereit stellt (wie unser Sir das beschrieben hat) sieht das natürlich schon anders aus. Dann ist das durchaus sinnvoll.

In dem Fall stellt sich mir "lediglich" die Frage, ob sich das nicht mit weniger Aufwand erreichen ließe.

Die Frage ist also nicht OB man ein gutes Konzept durchhalten soll, sondern wie man das am besten organisiert.

Mein Wunsch wäre "Für den Programmierer so einfach wie möglich incl. Einhaltung einer guten Wartbarkeit und Scalierung und für den Endanwender eine attraktive GUI".

Ich hatte mich damals für Pascal/Delphi entschieden weil mir die Sprache und später die RAD-Entwicklung als ein einfacher Weg der Programmierung erschien. Natürlich lernt man dazu und die Anforderungen steigen. Aber möglichst einfach will ich es immer noch haben. ;-)

[Sir Rufo]

Hier mal ein Beispiel zu einem simplen aber sehr effektiven Beispiel was man bei .net findet
http://www.codeproject.com/Articles/...ying-Recursion

Ein TreeView-Walker ... da hätte man auch selber mal drauf kommen können und hier der Delphi-Code dazu, der dem quasi 1:1 dem entspricht und auch so verwendet werden kann (der hier ist für FMX):

Delphi-Quellcode:

  TProcessNodeEventArgs = class( TEventArgs )
  private
    FNode: TTreeViewItem;
    FProcessDescendants: Boolean;
    FProcessSiblings: Boolean;
    FStopProcessing: Boolean;
  public
    constructor Create( ANode: TTreeViewItem );
    property Node: TTreeViewItem read FNode;
    property ProcessDescendants: Boolean read FProcessDescendants write FProcessDescendants;
    property ProcessSiblings: Boolean read FProcessSiblings write FProcessSiblings;
    property StopProcessing: Boolean read FStopProcessing write FStopProcessing;
  end;

  IProcessNodeEvent = IEvent<TProcessNodeEventArgs>;
  ProcessNodeEvent = Event<TProcessNodeEventArgs>;

  TTreeViewWalker = class( TComponent )
  private
    FTreeView: TTreeView;
    FStopProcessing: Boolean;
    FProcessNode: ProcessNodeEvent;
    function GetProcessNode: IProcessNodeEvent;
    function WalkNodes( ANode: TTreeViewItem ): Boolean;
  public
    constructor Create( ATreeView: TTreeView ); reintroduce;
    procedure ProcessTree;
    property ProcessNode: IProcessNodeEvent read GetProcessNode;
  end;

{ TProcessNodeEventArgs }

constructor TProcessNodeEventArgs.Create( ANode: TTreeViewItem );
begin
  inherited Create;
  FNode := ANode;
  FProcessDescendants := True;
  FProcessSiblings := True;
  FStopProcessing := False;
end;

{ TTreeViewWalker }

constructor TTreeViewWalker.Create( ATreeView: TTreeView );
begin
  if not Assigned( ATreeView )
  then
    raise EArgumentNilException.Create( 'ATreeView' );

  inherited Create( ATreeView );
  FTreeView := ATreeView;
end;

function TTreeViewWalker.GetProcessNode: IProcessNodeEvent;
begin
  Result := FProcessNode;
end;

procedure TTreeViewWalker.ProcessTree;
var
  LIdx: Integer;
begin
  FStopProcessing := False;
  for LIdx := 0 to FTreeView.Count - 1 do
    if not WalkNodes( FTreeView.ItemByIndex( LIdx ) ) or FStopProcessing
    then
      Break;
end;

function TTreeViewWalker.WalkNodes( ANode: TTreeViewItem ): Boolean;
var
  LArgs: TProcessNodeEventArgs;
  LIdx: Integer;
begin
  LArgs := TProcessNodeEventArgs.Create( ANode );
  try
    FProcessNode.Invoke( FTreeView, LArgs, False );
    Result := LArgs.ProcessSiblings;
    if LArgs.StopProcessing then
      FStopProcessing := True
    else begin
      if LArgs.ProcessDescendants then
      begin
        for LIdx := 0 to ANode.Count - 1 do
        begin
          if not WalkNodes(ANode.Items[LIdx]) or FStopProcessing then
            Break;
        end;
      end;
    end;
  finally
    LArgs.Free;
  end;
end;

[mquadrat]

Zitat:

Zitat von stahli (Beitrag 1286957)

Mein Wunsch wäre "Für den Programmierer so einfach wie möglich incl. Einhaltung einer guten Wartbarkeit und Scalierung und für den Endanwender eine attraktive GUI".

Naja, wer will das nicht :lol:

MVVM erschien mir dafür als geeignete Lösung. Allerdings legen wir alle neuen Projekte inzwischen als Web-App aus. Und bei der Überarbeitung von Legacy-Code hat man halt keine grüne Wiese.


@Stevie

Meiner einer wäre beim Bauen eines neuen Anwendungsframeworks dabei. Sofern wir dann über ein aktuelles Delphi verfügen. Mit XE2 - das wir aktuell einsetzen - macht das wenig Sinn.