AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

MVVM Framework für Delphi

Ein Thema von mquadrat · begonnen am 1. Nov 2010 · letzter Beitrag vom 19. Jan 2015
Antwort Antwort
Seite 5 von 6   « Erste     345 6      
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.861 Beiträge
 
Delphi 11 Alexandria
 
#41

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 09:48
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.
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.475 Beiträge
 
Delphi 12 Athens
 
#42

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 11:35
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
vagtler

Registriert seit: 9. Jul 2010
Ort: Köln
667 Beiträge
 
Delphi 2010 Professional
 
#43

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 12:16
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?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.861 Beiträge
 
Delphi 11 Alexandria
 
#44

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 12:17
Sorry, ich werde in Der Zukunft die Schauze halten!!!!!!
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#45

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 12:23
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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.641 Beiträge
 
#46

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 14:09
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 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.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.625 Beiträge
 
Delphi 12 Athens
 
#47

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 16:07
[OT]
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 [/OT]
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.343 Beiträge
 
Delphi 11 Alexandria
 
#48

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 16:36
@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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#49

AW: MVVM Framework für Delphi

  Alt 18. Jan 2015, 20:07
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;
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#50

AW: MVVM Framework für Delphi

  Alt 19. Jan 2015, 07:08
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

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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 5 von 6   « Erste     345 6      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz