Neues Projekt unter .Net: c# oder Prism

[Elvis]

Zitat von Phoenix:

Zitat von adeptus:

Ach noch was...
Lohnt sich die "Enterprise"-Version von Prism in meinem Fall?

Ehrlich gesagt (lass das aber niemanden von Embarcadero lesen ) lohnt sich die Enterprise-Version gar nicht. .NET hat mit ADO.NET schon alles an DB-Connectivity was man sich wünschen kann an Bord und wenn man eh .NET macht benutzt man auch kein DataSnap sondern 'richtige' N-Tier Frameworks bzw. auch die .NET Hausmittel wie z.B. WCF oder ganz normale Webservices.

Ich hatte vorhin schon eine Antwort geschrieben und mich entschlossen, sie lieber runterzuschlucken.
Ich hätte das nämlich nicht so überaus freundlich ausgedrückt.

[adeptus]

Zitat von Phoenix:

Zitat von adeptus:

Ach noch was...
Lohnt sich die "Enterprise"-Version von Prism in meinem Fall?

Ehrlich gesagt (lass das aber niemanden von Embarcadero lesen ) lohnt sich die Enterprise-Version gar nicht. .NET hat mit ADO.NET schon alles an DB-Connectivity was man sich wünschen kann an Bord und wenn man eh .NET macht benutzt man auch kein DataSnap sondern 'richtige' N-Tier Frameworks bzw. auch die .NET Hausmittel wie z.B. WCF oder ganz normale Webservices.

So was in der Art hatte ich im Gefühl... Danke!

[HeZa]

Zitat von adeptus:

Tja, das ist des Pudels Kern. Ich habe jahrezehnte lange Delphi-Erfahrung und bin kein zwanzig mehr... (ja ok, schreiben wir's auf: Ich bin 44 ). Ich bin immer hoch interessiert Neues zu lernen, doch in diesem Projekt muß ich vor allem effizient (ließ "schnell fertig") sein. Ich weiss genau, dass ich in C#/WPF erst eine steilere Lernkurve hätte... Deswegen schien Prism attraktivt unterstützt werden???

Du hast ja bis jetzt noch nicht viel über das Projekt gesagt. Da wundere ich mich schon das die Leute hier so fleißig Vorschläge mach was man verwenden soll.

• Wie viele Zeilen Code hat das Projekt?
• Wie viele Dialoge werden aufgerufen?
• Wie viele Entwickler programmieren daran herum?
• Wie häufig muss die Anwendung weiterentwickelt werden?

Eine komplette Neuentwicklung kann eine Chance sein, auf jeden Fall birgt sie auch große Risiken.

Als Entwickler neigt man dazu die Code-Qualität schlecht zu reden und würde nur zu gerne eine Neuentwicklung starten. Oft wird dabei die Menge an Code (der zwar grauselig aussieht, aber funktioniert) übersehen die es dabei zu ersetzen gilt.

Wenn nur Du an der Anwendung programmierst musst Du bei einer neu Entwicklung auch immer noch die Wartung bewerkstelligen. Da kann dann schnell jeder gut gemeinte Zeitplan ins Hintertreffen geraten. Bei einem gleichzeitigen Umstieg auf eine neue Programmiersprache/Entwicklungsumgebung wird es schwer sein die Anwendungsqualität gleich hoch zu halten (Und die funktionnalität muss ja da sein sonst hätte Ihr es ja schon längst in die Tonne getreten).

Meine Annahmen: Du bist der alleinige Entwickler/Tester/Dialog-Designer, die Anwendung ist groß (100 Tabellen, 100 Dialoge, min. 250000 Zeilen Code). Der Datenzugriff erfolgt großtenteils noch Tabellenorientiert. Da dann auch noch gilt: "doch in diesem Projekt muss ich vor allem effizient (ließ "schnell fertig") sein" würde ich zu folgender Strategieraten raten:

Schritt 1: Komponenten Migration

• Migration der Anwendung auf Delphi 2700 (um die Unicode-Migration erst mal heraus zu halten)
  Alle nicht mehr verfügbaren Komponenten und Bibliotheken durch aktuelle (die es auch für DelphiXE gibt) ersetzen.
• Diese Version ausliefern und mit arbeiten lassen

Schritt 2: Datenbank Migration

• Die BDE durch Advantage Database ersetzt (die kommt sehr gut mit dem tabellenorientierten arbeiten zurecht und ist trotzdem eine super SQL-Datenbank, sehr leicht zu installieren und zu pflegen.
• Diese Version ausliefern und mit arbeiten lassen

Schritt 3: Unicode Migration

• Immer noch Delphi 2007. Durchforste deine Units nach alten String verarbeitenden Routinen die vielleicht sogar noch mit PChar arbeiten und ersetze diese durch Standardversion aus SysUtils/StrUtils oder der JCL (nicht JVCL).
• Diese Version ausliefern und mit arbeiten lassen
• Migriere auf Delphi XE
• Diese Version ausliefern und mit arbeiten lassen

Du hast nun dein Anwendung in einer Entwicklungsumgebung die richtig Spaß macht, mit Du Dich nach kurzer Einarbeitungszeit sehr effizient arbeiten kannst und die Dir eine gute Unterstützung beim Refactoring dein Anwendung bietet.

Schritt 4: DesktopDB nach SQL Migration

• Ersetze tabellenorientiertes arbeiten durch SQL.
• Nutze die Features deiner Datenbank (Stored Procedures, Triggers, Volltextsuche)
• Diese Version ausliefern und mit arbeiten lassen

Schritt 5: Modernisierung/Weiterentwicklung

• Verbesser nach und nach den Code (Refactoring)
• Entwickle deine CleanCode-Mentalität
• Ändere immer das zu erst das deiner Firma (die bezahlen Dich) den meisten nutzen bringt

Egal wie Du Dich entscheidest, ich wünsche Dir viel Erfolg.

[adeptus]

Zitat von HeZa:

• Wie viele Zeilen Code hat das Projekt?
  ca. 65000
• Wie viele Dialoge werden aufgerufen?
  ca. 80
• Wie viele Entwickler programmieren daran herum?
  Genau: 1 (me, myself and I)
• Wie häufig muss die Anwendung weiterentwickelt werden?
  Es ist eine eigenständige Anwendung für EINEN einzigen Kunden. Es gibt zwar hier und da immer wider kleine Änderungswünsche, aber in den letzten Jahren ist die Anwendung schon sehr stabil was die Grundfunktionalität angeht.

Zitat von HeZa:

Als Entwickler neigt man dazu die Code-Qualität schlecht zu reden und würde nur zu gerne eine Neuentwicklung starten. Oft wird dabei die Menge an Code (der zwar grauselig aussieht, aber funktioniert) übersehen die es dabei zu ersetzen gilt.

Ich rede das nicht schlecht. Die Anwendung ist 15 Jahre alt. Es war schon ein kleiner Krampf sie auf Windows XP und dann Vista zu hieven... Paradox ist schon lange an seine Grenze angekommen (zum Beispiel das Problem mit großen Festplatten die dazu führen, dass Paradox denkt, die Platte sei voll...). Ich warte eigentlich täglich darauf, dass irgendwo irgendwas schlechtes passiert...

Zitat von HeZa:

Wenn nur Du an der Anwendung programmierst musst Du bei einer neu Entwicklung auch immer noch die Wartung bewerkstelligen.

Die Wartung (und vor allem auch die Verantwortung) habe ich sowieso nebenberuflich an der Backe... Gerade die Verantwortung macht es nötig langsam etwas zu ändern...

Zitat von HeZa:

Da kann dann schnell jeder gut gemeinte Zeitplan ins Hintertreffen geraten. Bei einem gleichzeitigen Umstieg auf eine neue Programmiersprache/Entwicklungsumgebung wird es schwer sein die Anwendungsqualität gleich hoch zu halten (Und die funktionnalität muss ja da sein sonst hätte Ihr es ja schon längst in die Tonne getreten).

Ja, an sich ist die Funktionalität da. Aber wie lange kann ich garantieren, dass alles läuft?

Zitat von HeZa:

...
Egal wie Du Dich entscheidest, ich wünsche Dir viel Erfolg.

Vielen, vielen Dank für diesen Projekt-Fluß. Macht einen sehr durchdachten Eindruck. Hast Du so was schon gemacht? Sprichst Du aus Erfahrung?

Werde mir auf alle Fälle mal die Advantage-DB anschauen. Ist doch die von SyBase, oder?

[jaenicke]

Zitat von adeptus:

Paradox ist schon lange an seine Grenze angekommen (zum Beispiel das Problem mit großen Festplatten die dazu führen, dass Paradox denkt, die Platte sei voll...). Ich warte eigentlich täglich darauf, dass irgendwo irgendwas schlechtes passiert...

Um genau zu sein tritt das auf, wenn der freie Speicher ein Vielfaches des maximalen Wertes annimmt. Dafür gibt es einen Patch:
http://cc.embarcadero.com/item/21475
(falls du das irgendwo noch kurzfristig fixen willst)

[adeptus]

Zitat von jaenicke:

Zitat von adeptus:

Paradox ist schon lange an seine Grenze angekommen (zum Beispiel das Problem mit großen Festplatten die dazu führen, dass Paradox denkt, die Platte sei voll...). Ich warte eigentlich täglich darauf, dass irgendwo irgendwas schlechtes passiert...

Um genau zu sein tritt das auf, wenn der freie Speicher ein Vielfaches des maximalen Wertes annimmt.

Ja genau, deswegen kopiere ich dann auf dem Server immer sinnlos riesige Verzeichnisse bis die Anwendung wieder läuft...

Zitat von jaenicke:

Dafür gibt es einen Patch:
http://cc.embarcadero.com/item/21475
(falls du das irgendwo noch kurzfristig fixen willst)

Ach... Wusste ich gar nicht... Danke!

[hanspeter]

Zitat von adeptus:

Es ist eine eigenständige Anwendung für EINEN einzigen Kunden. Es gibt zwar hier und da immer wider kleine Änderungswünsche, aber in den letzten Jahren ist die Anwendung schon sehr stabil was die Grundfunktionalität angeht.

Unter diesen Umständen bist Du glaub ich besser beraten, wenn Du bei Deelphi bleibst.
Du hast einen funktionierenden praxiserprobten Code.
Rechne einmal aus, wieviel Mannstunden in dem Code stecken. Mit neuer Sprache multipliziere das mit 2 und du bist bei dem minimalen Zeitbedarf.

An deiner Stelle würde ich vorsichtig mit der Migration auf XE bzw. den Nachfolger beginnen.
Dann die Datenbasis austauschen. Hier von Paradox auf ein Client/Server System.
Mit Firebird (kostenfrei) bist Du da nicht schlecht beraten.
Dort wo der Code schwer lesbar ist, mit Refaktoring aussagekräftigere Namen.
Evenduell für die Datenhaltung eine Zwischenschicht einziehen.

Ich würde wie gesagt so vorgehen, das ich immer ein lauffähiges Programm habe.
Die gleiche Aufgabenstellung hatte ich vor 3 oder 4 Jahren. Ein international eingeführtes Produkt von Paradox auf CS umstellen.
Geplant waren 6 Monate. Schon nach 1,5 Jahren waren wir fast fertig.

Gruß
Peter

[mquadrat]

Zitat von HeZa:

Migration der Anwendung auf Delphi 2700 (um die Unicode-Migration erst mal heraus zu halten)

Da muss er aber noch ne ganze Weile warten mit der Migration




@MVVM Framework
Irgendwer hatte noch nach eine .NET MVVM Framework gefragt. Ich hatte mich für Caliburn.Micro entschieden.

[Elvis]

Zitat von hanspeter:

An deiner Stelle würde ich vorsichtig mit der Migration auf XE bzw. den Nachfolger beginnen.

Nein, max. D2007 für die erste Iteration in der Richtung.
Denn es wird schlimm genug sein, auf ein neueres Delphi umzurüsten. Gleichzeitig Unicode zu bekämpfen ist unverhältnismäßig.

Nachdem er bei D2007 ist, kann er ENTWEDER erst Unicode -> XE angehen, ODER Paradox gegen ein C/S DBMS tauschen.
Wieder: Zuviele Änderungen in einer Iteration sorgt für zu viele Stellen, an denen nicht mehr genau nachvollzogen werden kann, wie sich das System denn überhaupt verhalten wird.

Der Plan, den HeZa umrissen hat, klingt doch ganz vernünftig.

[adeptus]

@ALL: Nochmals vielen Dank für die Rege Beteiligung!

Zitat von mquadrat:

...

@MVVM Framework
Irgendwer hatte noch nach eine .NET MVVM Framework gefragt. Ich hatte mich für Caliburn.Micro entschieden.

Ja, die Frage hatte ich wohl gestellt. Würdest Du (ihr) eigentlich empfehlen, unter den von mir beschrieben Bedingungen, auf MVVM zu setzen oder ist das zu komplex für einen Einzelkämpfer unter Zeitdruck? MVC habe ich schon mehrmals implementiert und mit MVVM habe ich mal eine Dummy-Demo-Mini-Anwendung geschrieben. Aber sowas habe ich nie als Einzelkämpfer gemacht. Zumeist braucht man dann ja noch andere Frameworks und einen IOC-Container, und, und, und...

Das kann einer alleine doch nicht alles evaluieren, testen und implementieren...