Lohnt sich der kauf von Delphi Prism überhaupt?

[Andreas2k]

Ich habe nun einen kleinen Eindruck durch die Prism Trialversion sammeln können. Nun frage ich mich aber ob es sich überhaupt lohnt Prism zu kaufen oder ob ich nicht lieber gleich in Microsofts Visual Studio und C# investieren sollte.

Hauptgrund für mich um überhaupt mit .NET zu arbeiten wäre WCF und Silverlight. Für beides macht es eigentlich Sinn Microsoft Standard Tools für Design zu verwenden (Expression Blend bzw. Design) und die XAML Daten zu gestalten.

In einer Tutorial DVD von Video2Brain zum Thema Silverlight/WPF wurde auch mehrfach hingewiesen das Blend direkt mit dem Projektformat von MS Visual Studio 2010 zusammenarbeitet und das es daher möglich ist, jede Programmiersprache die in Visual Studio läuft und dessen Projektformat nutzt, zu verwenden.

Mit Delphi Prism geht das ärgerlicherweise nicht. Ich kann weder das Projektfile in Blend öffnen noch die XAML Dateien (weder in Blend noch Design)

Daher auch meine Frage:

Lohnt es überhaupt in Prism zu investieren wenn,
- es so etwas wie die aus Delphi bekannte VCL nicht gibt?
- es nicht zu MS Standardtool's kompatibel ist obwohl es in MS VS 2010 läuft?

oder sollte man doch lieber in den sauren Apfel beißen und c# lernen?

[Medium]

Keine Antwort auf die konkrete Frage, aber dennoch korrigierenswert: C# ist kein saurer Apfel. Ich als Delphi-Muttersprachler bin vergleichsweist flott rein gekommen, und schätze es mittlerweile sehr. Es ist im .NET Umfeld sicherlich keine blöde Idee sich mit der nativen Sprache zu bewegen, so man denn die Muße hat dort einzusteigen (bzw. keine Altlasten in anderen Sprachen super schnell portieren muss).
Ich will Prism gar nicht schlecht reden (kann ich mangels Erfahrung nichtmals), aber ich kann durchaus für C# eine Lanze brechen - so als C-Dialekt-Skeptiker =)

[mkinzler]

Zitat:

- es nicht zu MS Standardtool's kompatibel ist obwohl es in MS VS 2010 läuft?

Das ist kein Problem von Prsim, sondern von MS. Auch hier sind manchen Sprachen gleicher, obwohl alle gleich sind

[Florian Hämmerle]

Zitat von Medium:

sicherlich keine blöde Idee sich mit der nativen Sprache zu bewegen

Hmm wie jetzt? Meinst du etwa, dass alles was auf .NET läuft C# ist?

Delphi Prism ist sicher eine nette Sache, wird ständig weiterentwickelt und mir gefällts. Hab zwar auch erst die Trial am Laufen, doch mit ihr hab ich eigentlich alles, was ich hinbekommen wollte hinbekommen. Ausnahmen sind die von dir genannten "Feindlichkeiten" zwischen Blend und VS.

mfg Florian

[Phoenix]

Zitat von mkinzler:

Zitat:

- es nicht zu MS Standardtool's kompatibel ist obwohl es in MS VS 2010 läuft?

Das ist kein Problem von Prsim, sondern von MS. Auch hier sind manchen Sprachen gleicher, obwohl alle gleich sind

Mit F#-Projekten kommt Blend btw. auch nicht zurecht. Und F# wird inzwischen sogar als 'First Class Citizen' in der MS-Entwicklungswelt bezeichnet. Das ist wirklich kein Problem von Prism sondern vom Blend-Team bei Microsoft.

Bug Report einreichen ist das einzige was helfen kann.

Zu C#: Wenn man .NET ernsthaft entwickeln will (egal in welcher Sprache), sollte man dennoch mindestens C# auf jeden Fall kennen.
Auch wenn C# hinter Prism immer noch massiv hinterherhinkt - schliesslich haben die noch kein integriertes AOP, und so nette Dinge wie boolean-double-comparisons ( if (x < myVar < y) then... ). Auch Interface delegation und die vereinfachte Extension-Method Syntax ist etwas, was ich in C# schmerzlich vermisse, und zwar jedes mal wenn ich damit arbeite.

Die Frage ist also eher, soll man, nur weil Microsoft es nicht gebacken bekommt sein eigenes Projektformat zu lesen wenn in einem Attribut im XML ein Wert drin steht, den sie nicht erwarten, auf den ganzen Sprachkomfort und die Fortschrittlichkeit von Prism verzichten?

Wir sind hier in der .NET Welt - also warum nicht z.B. die Business-Logik und auch das WPF bzw. Silverlight ViewModel komplett in Prism schreiben und ausschliesslich die Oberfläche die diese Objekte dann nur noch databindet in einem separaten C#-Projekt machen das ausser dem generierten keinen anderen Code hat? Das hilft sogar noch zusätzlich, das Projekt sauber zu halten indem man keinen Logik-Code in die Präsentationsschicht bringen kann.

Ich würde sagen nicht entweder oder, sondern ein ganz klares und: Jede Sprache dort einsetzen, wo es am meisten Sinn macht und am effizientesten ist.

[mquadrat]

Ich entwickle sowohl in Delphi als auch in C#. Trotzdem würde ich nie auf die Idee kommen Delphi Prism zu verwenden. Wenn man in .NET arbeitet MUSS man C# können. Sämtliche Beispiele, Libraries etc sind in C# geschrieben. Wenn man sich das also sowieso aneignen muss, warum dann nochmal Prism draufsetzen? Dazu kommt noch, dass man wennn man in einer anderen Syntax programmiert seltener Klassen, Befehle, Konstanten etc vertauscht, wenn man wie ich parallel in beiden Welten arbeitet.

[Medium]

Zitat von Florian Hämmerle:

Zitat von Medium:

sicherlich keine blöde Idee sich mit der nativen Sprache zu bewegen

Hmm wie jetzt? Meinst du etwa, dass alles was auf .NET läuft C# ist?

Nativ in dem Sinne, dass C# begleitend und zielgerichtet zu .NET entwickelt wurde/wird, und nicht eine Anpassung einer anderen Sprache darstellt. Und während sicher nicht alles .NETtige in C# verfasst ist, so ist es doch ein deutlich überwiegender Anteil. Dies zumindest verstehen zu können ist ein immenser Vorteil in diesem Umfeld.

[Phoenix]

Zitat von mquadrat:

Wenn man sich das also sowieso aneignen muss, warum dann nochmal Prism draufsetzen?

Weil man mit Prism irgendwo zwischen einem Drittel und der Hälfte des in C# benötigten Codes einspart, weil der Compiler einem massiv arbeit abnimmt z.B. durch die automatische Implementation von INotifyPropertyChanged, Interface Delegation und auch Cirrus hilft richtig viel Code einzusparen wenn man es gezielt einsetzt.

Dazu kommt dann noch, das Pascal-Code nunmal einfacher lesbar ist als C-Style und damit zu einem viel höheren Code-Verständnis und damit zu mehr Wartbarkeit führt.

[Uwe Raabe]

Zitat von Phoenix:

Dazu kommt dann noch, das Pascal-Code nunmal einfacher lesbar ist als C-Style und damit zu einem viel höheren Code-Verständnis und damit zu mehr Wartbarkeit führt.

Amen!

[mz23]

Zitat von Uwe Raabe:

Zitat von Phoenix:

Dazu kommt dann noch, das Pascal-Code nunmal einfacher lesbar ist als C-Style und damit zu einem viel höheren Code-Verständnis und damit zu mehr Wartbarkeit führt.

Amen!

Die Delphi-XE Version scheint Ihr neuer Liebling zu sein

Leider ist es mir nicht möglich gewesen, einen Trial-Schlüssel
email-technisch zu empfangen, da die auf dem Olymp lebenden
Delphi-XE-Entwickler der Meinung sind, ihre EMail ging in
meinen Spam-Ordner! Und ich bin zu blöde, dort nachzusehen.

PS: Ich erinnere nur an die Java Programmiersprache die
Unterschiede zwischen Groß/Klein-Schreibung macht
und in der Leerzeichen zwischen Zuweisungs-Code anderes
bewirken können.

Amen!