Neues Projekt unter .Net: c# oder Prism

[Elvis]

Zitat:

Zitat von Phoenix (Beitrag 1113029)

Zitat:

Zitat von adeptus (Beitrag 1113012)

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. :oops:

[adeptus]

Zitat:

Zitat von Phoenix (Beitrag 1113029)

Zitat:

Zitat von adeptus (Beitrag 1113012)

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:

Zitat von adeptus (Beitrag 1112845)

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:

Zitat von HeZa (Beitrag 1113085)

• 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:

Zitat von HeZa (Beitrag 1113085)

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:

Zitat von HeZa (Beitrag 1113085)

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:

Zitat von HeZa (Beitrag 1113085)

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:

Zitat von HeZa (Beitrag 1113085)

...
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:

Zitat von adeptus (Beitrag 1113423)

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:

Zitat von jaenicke (Beitrag 1113426)

Zitat:

Zitat von adeptus (Beitrag 1113423)

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... :wall:

Zitat:

Zitat von jaenicke (Beitrag 1113426)

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:

Zitat von adeptus (Beitrag 1113423)

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:

Zitat von HeZa (Beitrag 1113085)

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

:shock: 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:

Zitat von hanspeter (Beitrag 1113507)

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! :thumb:

Zitat:

Zitat von mquadrat (Beitrag 1113529)

...

@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... :?

[adeptus]

Zitat:

Zitat von Elvis (Beitrag 1113576)

Zitat:

Zitat von hanspeter (Beitrag 1113507)

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. :-)

Ja, wenn man davon ausgeht, dass das UI so bleiben soll wie es ist, klingen die Schritte nachvollziehbar und sinnvoll.

Aber dieses alte UI gehört mit zu den Sachen die weg müssen... Und daran müssen sich die User so schnell wie möglich gewöhnen. Deswegen stelle ich mir da so vor:

1. Neues UI / Workspace erstellen und vorstellen
2. Erste Teile der Anwendung auslagern in das neue UI (neu entwickeln). Das bedeutet, beide Anwendung müssten parallel laufen. Zum Beispiel wird die reine Verwaltung der Kundendaten in das neue UI "verschoben", der Rest bleibt noch in der alten Anwendung. Problem dabei: der Datenaustausch... Die alte Anwendung nutzt noch Paradox, die neue etwas anderes...
3. Immer mehr Module in der neuen Anwendung neu integrieren, bis in der alten nix mehr übrig ist... :-)

Das größte Problem dabei wäre wie erwähnt die Datenbank. Gibt es ADO .Net treiber für "Paradox"? Ich denke das wäre einfacher, als der alten Anwendung beizubringen mit MySQL, SQL-Server oder Firebird umzugehen...

Die andere Möglichkeit wäre eine "Big Bang" Umstellung nachdem die User eine Zeit lang alles zweifach machen. 1x in der alten, 1x in der neuen Anwendung und die Ergebnisse vergleichen...

[stahli]

Ich würde so wenig wie möglich von der bisherigen Umgebung abweichen.

Sofern ein Problem besteht (die Stabilität der Datenbank) würde ich NUR DIESES ändern.
Sofern Du TTables eingesetzt hast wird es schon schwer genug werden, das Projekt komplett auf einen SQL-Server zu portieren.

Was willst Du erreichen? Wieviel Zeit hast Du?

Sich in eine komplette neue Umgebung (Net - egal ob Prism oder C#) einzuarbeiten, macht man nicht in ein paar Wochen.

Ich würde mich ehr darauf konzentrieren, das Projekt mit wenig Aufwand und Abweichungen stabil zu kriegen und für neue Projekte neue Umgebungen zu testen.

Anders wäre es, wenn Du Dein Projekt auch künftig über Jahre immer weiter ausbauen willst, dann wäre ein kompletter Umstieg evtl. zu überlegen.
Ich würde da aber mal duchaus 1-2 Jahre ansetzen. Schon allein die Entscheidung, auf welche neue Umgebung man denn nun setzen soll, kann ja einige Tage dauern. ;-)

[adeptus]

Zitat:

Zitat von stahli (Beitrag 1113638)

Ich würde so wenig wie möglich von der bisherigen Umgebung abweichen.

Sofern ein Problem besteht (die Stabilität der Datenbank) würde ich NUR DIESES ändern.
Sofern Du TTables eingesetzt hast wird es schon schwer genug werden, das Projekt komplett auf einen SQL-Server zu portieren.

Was willst Du erreichen? Wieviel Zeit hast Du?

Es soll schon ein kompletter neubau sein. Ich will im Rahmen dessen meine Kenntnisse in C#, .Net4 stark erweitern. Das ist auch eine der Triebfedern für das Projekt. Der Kunde hat was zukunftfähiges und sicheres, ich lerne endlich wieder was dazu! :-)

Zitat:

Zitat von stahli (Beitrag 1113638)

Sich in eine komplette neue Umgebung (Net - egal ob Prism oder C#) einzuarbeiten, macht man nicht in ein paar Wochen.

Ich plane schon ein Jahr Arbeit aber verteilt auf 2 Jahre, da ich das nur 2-3 Tage die Woche machen kann...

Zitat:

Zitat von stahli (Beitrag 1113638)

Ich würde mich ehr darauf konzentrieren, das Projekt mit wenig Aufwand und Abweichungen stabil zu kriegen und für neue Projekte neue Umgebungen zu testen.

Anders wäre es, wenn Du Dein Projekt auch künftig über Jahre immer weiter ausbauen willst, dann wäre ein kompletter Umstieg evtl. zu überlegen.

Ich werde dieses "Ding" die nächsten Jahre immer weiter pflegen. Wenn's ein mal umgestellt ist, wird zwar nicht mehr viel zu tuen sein, doch irgendwelche Sachen werden immer kommen.

Zitat:

Zitat von stahli (Beitrag 1113638)

...Schon allein die Entscheidung, auf welche neue Umgebung man denn nun setzen soll, kann ja einige Tage dauern. ;-)

Wem sagst Du das... ;-)