Neues Projekt unter .Net: c# oder Prism

[adeptus]

Zitat:

Zitat von hanspeter (Beitrag 1112821)

So wie es in der Gerüchteküche von MS zu W8 klingt, geht es wohl in die Richtung GUI Oberfläche auf WEB-Basis (HTML5) und die Bussineslogik in Net.

Wobei man dann noch immer einen Browser braucht (der dann auch noch HTML5 beherrschen muss). Diese Anwendung würde aber mit einem Fat-Client daher kommen. Ich würde zwar eine Schichtentrennung durhalten wollen (Multi-Layer) aber keine verteilte Anwendung planen (Multi-Tier).

Zitat:

Zitat von hanspeter (Beitrag 1112821)

Ob C# oder Prism oder Delphi würde ich von der Qualifikation und Alter der Programmierer abhängig machen. Wenn jahrelange Erfahrungen in Delphi/Pascal und tonnenweise Delphicode vorhanden ist, dann ist es effektiver bei Pascal zu bleiben.

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 attraktiv

Zitat:

Zitat von hanspeter (Beitrag 1112821)

Ob Net oder nativ muss man abwarten, was XE2 bringt.
Hier habe ich durchaus meine Bedenken. Neue Technologien aus der Delphirichtung gingen bisher mehr oder weniger immer schief. Ich möchte mich nicht gern auf ein Framework oder ähnliches einlassen, wo ich nicht weis, ob es das nächstes Jahr noch gibt. (Blackfisch,CLX)

Genau davor habe ich Angst...

Zitat:

Zitat von hanspeter (Beitrag 1112821)

Prism dürfte insgesamt zukunftssicher sein, da ich zukünftig für 2 Plattformen (Net,Java) entwickeln kann und mit C# auf Assembly Basis linken kann.
Insgesamt würde ich mit der Entscheidung bis zum Herbst warten, was sich mit Delphi tut.
Native Programme haben durch auch noch ihren Reiz.
Auf Basis der jetzigen VCL, würde ich keine Neuentwicklung mehr anfangen.

Meinst Du mit nativ WIN32? Also ohne .Net? Wie lange wird das noch von Windows in der Zukunft unterstützt werden???

[Bernhard Geyer]

Zitat:

Zitat von adeptus (Beitrag 1112845)

Meinst Du mit nativ WIN32? Also ohne .Net? Wie lange wird das noch von Windows in der Zukunft unterstützt werden???

Zwischen 1 Jahre und 20 Jahren. Wenn MS den ARM-Port rausbringt und deine Firme ARM-PC's einsetzt wirst du schon nächstes Jahr Probleme haben. Auf x86/x64-Systemen wird dein Programm unter Win32 auch in 10-20 Jahren noch laufen.

[Phoenix]

Zitat:

Zitat von adeptus (Beitrag 1112845)

Zitat:

Zitat von hanspeter (Beitrag 1112821)

Ob C# oder Prism oder Delphi würde ich von der Qualifikation und Alter der Programmierer abhängig machen. Wenn jahrelange Erfahrungen in Delphi/Pascal und tonnenweise Delphicode vorhanden ist, dann ist es effektiver bei Pascal zu bleiben.

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 attraktiv

Delphi Prism ist eigentlich nur eines: Die Oxygene-Language mit IDE Support.
Den Einarbeitungsaufwand in die .NET Plattform und die .NET Klassen hast Du so oder so.

Du sparst Dir mit Prism das Lernen der C#-Syntax, und Du hast mit Oxygene eine Sprache die zudem noch moderner ist und mehr Features mitbringt als C# es tut.

Und Du hast mit Prism eine Lösung, die auf Cross-Plattform getrimmt ist. Für MS C# gibt es keinen offiziellen Support für Mono. Für Oxygene schon. Mit C# kannst Du nichts für Java machen. Mit Oxygene schon (und mit Oxygene hat man in Java sogar Properties ;-) ).

Es ist halt nicht mehr das Pascal von vor 40 Jahren (war doch irgendwann Anfang der 70er, oder?), sondern Oxygene ist eine moderne Sprache, die einem die Arbeit mit modernen Plattformen leichter macht, ales es die Haussprachen selber tun.

Es gibt keinen Grund, sich initial den zusätzlichen Aufwand einer komplett anderen Syntax anzutun. Später kommt das von alleine, aber die Zeit kann man sich zu Beginn schonmal sparen.

[dataspider]

Zitat:

Zitat von Phoenix (Beitrag 1112862)

Es gibt keinen Grund, sich initial den zusätzlichen Aufwand einer komplett anderen Syntax anzutun.

Nur aus Interesse...
Wie sieht es mit Fremdkomponenten für Prism (z.B. die von Developer Express) aus?
Bekommt man das auch für Prism?

Frank

[hanspeter]

Zitat:

Zitat von dataspider (Beitrag 1112866)

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 attraktiv

Dann würde ich die Entscheidung von meinen weiteren beruflichen Plänen abhängig machen.
Möchte ich als Programmierer arbeiten, bin ich nicht schlecht beraten C# zu beherschen.
Das lernt man am besten bei der Realisierung eines Projektes. Darf aber nicht übersehen, das die Lernkurve den Fortschritt des Projektes erheblich verzögern kann. Erfolgt die Programmierung nebenbei oder in Eigenregie (z.B. selbstständig), dann ist oft dem Auftraggeber die Programmiersprache eher egal. In diesem Fall würde ich bei Pascal bleiben.
Wobei ich allein aufgrund der zukünftig möglichen Plattformen eher zu Prism bzw. seinem Nachfolger tendiere.
Allein über die JVM bin ich auf fast allen Plattformen. Ob Delphi das jemals kann?
Interessanter ist sicherlich, wie das Projekt realisiert werden soll und ob hier mehrschichtig in der klassischen Variante noch optimal ist.

Denkbar wäre z.B. durchaus eine GUI in einer beliebigen Sprache und die gesamte Verarbeitung auf den Server zu legen.
Ich experimentiere im Moment mit einem Lösungsansatz mit Firebird. Hier aktiviert eine durch Trigger aufgerufene stored Procedure ein externes Bearbeitungsprogramm das Datenänderungen bearbeitet.


Gruß
Peter

[adeptus]

Zitat:

Zitat von dataspider (Beitrag 1112866)

Zitat:

Zitat von Phoenix (Beitrag 1112862)

Es gibt keinen Grund, sich initial den zusätzlichen Aufwand einer komplett anderen Syntax anzutun.

Nur aus Interesse...
Wie sieht es mit Fremdkomponenten für Prism (z.B. die von Developer Express) aus?
Bekommt man das auch für Prism?

Frank

Sehr gute Frage!

In der Tat würde ich natürlich auf solche Komponentenbibliotheken zugreifen wollen, doch gerade DEV Express gibt's doch auch für .NET. Dann sollten das doch in der Visual Studio Shell einbindbar und in einer Prism-Anwendung verwendbar sein, oder?

[Phoenix]

Zitat:

Zitat von dataspider (Beitrag 1112866)

Nur aus Interesse...
Wie sieht es mit Fremdkomponenten für Prism (z.B. die von Developer Express) aus?
Bekommt man das auch für Prism?

Es sind .NET Komponenten. Wenn die mit .NET funktionieren, dann funktionieren die auch mit Prism ;-)
Alles, was echtes .NET ist (ADO.NET, Entity Framework, ASP.NET, ASP.NET MVC, NHibernate, Spring.NET, Nant, kommerzielle Komponenten, Open-Source-Bibliotheken) funktioniert mit Prism. Auch alles was mit Prism erstellt wird kann von C#, VB.NET, IronRuby, IronPython, F# und wie die ganzen anderen .NET-Sprachen da draussen noch heissen genutzt werden.

Einschränkungen gibt es potentiell da, wo es um Quellcode-Generierung und/oder -Parsing geht und das nicht über CodeDom oder Code.Emit gemacht wird.

Webservice-WSDL's in Oxygene-Code generieren geht z.B. auch einwandfrei, obwohl das ja auch Code-Generierung ist.

Der einzige Wermutstropfen sind tatsächlich z.B. Refactoring Tools von irgendwelchen anderen Anbietern. Die gehen in aller Regel nicht, weil die spezifisch für C# und ggf. VB geschrieben sind. Das geht dann aber auch nicht mit F#, was ja angeblich ein offizieller 'First Class Citizen' in der .NET Umgebung von Microsoft ist. Von daher relativiert sich das ein bisschen.

[adeptus]

Zitat:

Zitat von Phoenix (Beitrag 1112879)

Zitat:

Zitat von dataspider (Beitrag 1112866)

Nur aus Interesse...
Wie sieht es mit Fremdkomponenten für Prism (z.B. die von Developer Express) aus?
Bekommt man das auch für Prism?

Es sind .NET Komponenten. Wenn die mit .NET funktionieren, dann funktionieren die auch mit Prism ;-)
Alles, was echtes .NET ist (ADO.NET, Entity Framework, ASP.NET, ASP.NET MVC, NHibernate, Spring.NET, Nant, kommerzielle Komponenten, Open-Source-Bibliotheken) funktioniert mit Prism. Auch alles was mit Prism erstellt wird kann von C#, VB.NET, IronRuby, IronPython, F# und wie die ganzen anderen .NET-Sprachen da draussen noch heissen genutzt werden.

Genau das hätte ich auch erwartet! :thumb:

Zitat:

Zitat von Phoenix (Beitrag 1112879)

...
Das geht dann aber auch nicht mit F#, was ja angeblich ein offizieller 'First Class Citizen' in der .NET Umgebung von Microsoft ist. Von daher relativiert sich das ein bisschen.

Ach deswegen heisst die Sprache F# -> First Class Citizen

:lol:

[adeptus]

@all: vielen Dank für die rege Diskussion und die vielen Anregungen! :thumb:

Ich denke ich werde wohl doch direkt in C# beginnen. Die Erfahrungen die ich damit mache sind auf dem Markt gefragter und für die Zukunft sicherer...

Allerdings... Klingt Delphi Prism immer noch sehr verlockend... :gruebel:

Letztlich bräuchte man wirklich eine :glaskugel: um sowas zu entscheiden...

[Phoenix]

Zitat:

Zitat von adeptus (Beitrag 1112910)

@all: vielen Dank für die rege Diskussion und die vielen Anregungen! :thumb:

Ich denke ich werde wohl doch direkt in C# beginnen. Die Erfahrungen die ich damit mache sind auf dem Markt gefragter und für die Zukunft sicherer...

Allerdings... Klingt Delphi Prism immer noch sehr verlockend... :gruebel:

Letztlich bräuchte man wirklich eine :glaskugel: um sowas zu entscheiden...

Naja.. wie gesagt.. C# lernt man mit der Zeit automatisch. Und wenn man dann sieht, was man in Oxygene hat und in C# so schnell nicht bekommen wird, was einem aber massigst arbeit abnimmt, dann tun mir die C#'ler immer mehr leid. :twisted: