Einstieg in Prism, für MacOS geeignet?

[Linor]

Hallo Zusammen,

ich habe das eine Software die mit D2010 für Windows geschrieben wurde, recht groß und seeeeehr Datenbank-Lastitsch Da es sich dabei um eine Bildverwaltung handelt, habe ich oft Fragen ob es mein Programm auch für den Mac gibt, muss das leider immer verneinen

Nachdem ich mich jetzt mal so umgesehen habe was man so für CrossPlatform verwenden kann sind mir bisher nur Java und .NET auf Mono-Basis aufgefallen. Java kann ich, will ich aber nicht Prism habe ich da im Paket vom RAD-Studio rumfliegen, das wärs...

Aber: Bevor ich mir jetzt .NET antue, !! Null Erfahrung !! damit, habe ich zunächst mal ein paar Grundlegende Fragen dazu.

Kann man zu 100% eine Anwendung unter Windows prorgammieren die dann ohne Anpassungen auf einem Mac läuft? Hintergrund ist, ich habe keinen Mac und möchte nicht nach endlosen Monaten arbeit feststellen das es alles für die Katz war... Sich später, wenn man ein recht reifes Produkt, einen zu kaufen wird wohl notwendig, aber nicht am Anfang. Gibt es Möglichkeit zu sehen was man auf dem Mac zu sehen bekommen würde?

Wie erfolgen Datenbank-Zugriffe? Verwende zur Zeit UniDAC um auf 6 verschiedene Datenbanken zuzugreifen. Gibt es da ähnliche Komponenten? Benötigt man überhaupt Komponenten? (Wie gesagt, keinen Blick im moment von .NET)

Komponenten im allgemeinen? Das meine DevEx-Dinger so nicht laufen ist klar, ist ja VCL, aber gibt es für .NET auch sowas zu kaufen? Laufen diese dann auch unterm Mac? Sollte ja wenn Prism = CrossPlatform!?!?!

Läuft alles was es für .NET gibt dann unter Prism, Windows, Linux und MacOS????

Fragen über Fragen, aber denke das würde mir erstmal reichen

[Bernhard Geyer]

Zitat von Linor:

Kann man zu 100% eine Anwendung unter Windows prorgammieren die dann ohne Anpassungen auf einem Mac läuft?

Nein. Eine 100%ige Garantie kann es nicht geben. Du kannst auch nicht garantieren wenn du dein Programm unter XP Entwickelst das es unter Win7 läuft.

Zitat von Linor:

Hintergrund ist, ich habe keinen Mac und möchte nicht nach endlosen Monaten arbeit feststellen das es alles für die Katz war...

Willst du ernsthaft mit der Entwicklung anfangen heißt es: Kauf dir einen Mac!

Zitat von Linor:

Sich später, wenn man ein recht reifes Produkt, einen zu kaufen wird wohl notwendig, aber nicht am Anfang.

Doch. Wenn du ernsthaft damit Anfangen willst heißt es schon frühzeitig darauf testen.

Zitat von Linor:

Wie erfolgen Datenbank-Zugriffe? Verwende zur Zeit UniDAC um auf 6 verschiedene Datenbanken zuzugreifen.

Unter .NET nennt sich das ADO.NET.

Zitat von Linor:

Komponenten im allgemeinen? Das meine DevEx-Dinger so nicht laufen ist klar, ist ja VCL, aber gibt es für .NET auch sowas zu kaufen? Laufen diese dann auch unterm Mac? Sollte ja wenn Prism = CrossPlatform!?!?!

Es gibt genügend Kompos für .NET. Und ein erheblicher Teil wird (MONO und Co sei Dank) vermutlich auch unter MacOS laufen.

Zitat von Linor:

Läuft alles was es für .NET gibt dann unter Prism, Windows, Linux und MacOS????

Nein.

[daywalker9]

Zitat von Linor:

Kann man zu 100% eine Anwendung unter Windows prorgammieren die dann ohne Anpassungen auf einem Mac läuft? Hintergrund ist, ich habe keinen Mac und möchte nicht nach endlosen Monaten arbeit feststellen das es alles für die Katz war... Sich später, wenn man ein recht reifes Produkt, einen zu kaufen wird wohl notwendig, aber nicht am Anfang. Gibt es Möglichkeit zu sehen was man auf dem Mac zu sehen bekommen würde?

Nein, es gibt keine möglichkeit ohne Mac zu sehen, wie die Applikation auf einem Mac aussehen würde. Für die Cross-Plattform entwicklung ist es zwingend notwendig einen Rechner mit der jeweiligen Plattform zu haben. Da sich Applikationen auf anderen Plattform durchaus anders verhalten können.

Edit: Es muss ja kein MacBook Pro oder Air sein, ein Mac Mini reicht dafür vollkommen aus und liegt im unteren Preissegment (ca 500€).

[Phoenix]

Das meiste wurde schon gesagt.
Garantien gibt es nicht, und selbst der Mono Migration Analyzer der auf problematische API's hinweist ist nur eine Hilfestellung und kein Garant.

Auf einem Mac testen ist unentbehrlich, und wenn man die Cyclen kurz halten will, ist es sogar größtenteils empfehlenswert, direkt auf dem Mac zu entwickeln (dank Mono und MonoDevelop kein Problem). Der Mac Mini als günstigster Einstieg wurde ja schon genannt.

Ich würde aber aus diversen Gründen die in anderen Threads schon angesprochen wurden davon absehen, mit Windows Forms eine Applikation zu schreiben und die dann einfach auf dem Mac laufen zu lassen. Das geht zwar, aber das sieht hinterher echt Kacke aus und macht Probleme, weil einige Sachen nicht funktionieren (es gibt keine Messages und damit z.B. auch keine direkten Mouse-Events etc.). Auch gibt es keine mir bekannten GUI-Komponenten die unter Mono laufen. WPF ist eh aussen vor. Meiner Meinung nach ist es besser, das GUI für den Mac mit den MonoMac-Bindings (open source) zu erstellen, und damit dann native Mac-UI-Elemente zu verwenden, und das gleiche für Windows mit Windows Forms oder WPF zu machen.

Das heisst die Anwendung hat letztlich zwei GUI's im Bauch und benutzt das jeweilige Native für die jeweilige Plattform.

Datenbank ist dank ADO.NET und den jeweiligen Treibern der Datenbanken ein absoluter No-Brainer (wenn man auf zusätzliche Komponenten setzen will sei hier DevArt, formals Corelabs genannt, die sind wirklich tauglich, aber nicht unbedingt nötig).

[Linor]

Also wird einem bzgl. CrossPlatform und .NET respektive Prism/Mono nur etwas vorgegaukelt? Als letztlich nichts anderes als die Behauptung von früher "C" wäre auch kompatibel, das ganze aber den Bach runtergeht wenn man mehr als printf() verwenden möchte?

[implementation]

Die Systeme unterscheiden sich nunmal schon in ihrem Aufbau und ihrer Philosophie. Zaubern kann kein Compiler. Inwiefern ein Programm plattformunabhängig ist, hängt fast allein vom Programmierer ab.
Ja, man kann mit Mono Anwendungen für Windows, GNU(/Linux) und UNIX (Mac/BSD/...) schreiben, aber das hängt von dir ab.

Beispiel:
Angenommen du benutzt für Pfade immer Backslashes, dann ist es per se nur für Windows geeignet, wenn nicht irgendein Feature in der Bibliothek das wieder ausbügelt, denn unixoide Systeme haben eine andere Pfadsyntax.

Das ganze braucht Übung, bis man das abstrakter bekommt. Mittlerweile läuft eigentlich alles, was ich schreibe meist ohne Änderung gleichzeitig auf Windows und GNU/Linux. Das verdanke ich natürlich überwiegend FreePascal's RTL, FCL und LCL, die dafür schon einiges an Helfermethoden vorsehen.
Und mit dem von dir erwähnten C geht das genauso gut. Aber dann musst du halt auch selber etwas drauf achten, und nicht einfach für eine Plattform losproggen und erwarten, dass es auf den andern auf einmal auch läuft.

[Phoenix]

Zitat von Linor:

Also wird einem bzgl. CrossPlatform und .NET respektive Prism/Mono nur etwas vorgegaukelt? Als letztlich nichts anderes als die Behauptung von früher "C" wäre auch kompatibel, das ganze aber den Bach runtergeht wenn man mehr als printf() verwenden möchte?

So schlimm ist es jetzt nicht.
Mono unterstützt nunmal nicht alle Teile von .NET. Es fehlen noch Teile von WCF und WPF wird gar nicht unterstützt.
Das heisst im GUI-Bereich ist man, wenn man eine 'one size fits all'-Lösung haben will auf Windows Forms beschränkt, und muss dort eben mit den jeweiligen System-Einschränkungen leben, und im Kommunikationsbereich auf normale HTTP-Webservices und Sockets.

Alles andere, insbesondere im Bereich Datenbanken und sonstiger System I/O (mit Ausnahme von Message Queues, wo man am besten RabbitMQ nimmt um wirklich alle Plattformen abzudecken), ist unproblematisch. Das schliesst unter anderem auch ASP.NET ein.

Will heissen: .NET /Mono ist eine Plattform, die genau wie Java eher für den Server / das Backend gedacht ist, und eben nicht so sehr für die GUI.
GUI würde ich auf jeder Plattform nativ machen - mit den MonoMac Bindings kann man dann natürlich die nativen OS-Controls von OSX absolut schmerzfrei einbinden und hat hinterher eine Anwendung der man nicht ansieht, dass sie hinten drin eigentlich Mono verwendet.

Das bedeutet aber natürlich, dass man auf der Zielplattform auch testen muss.

[Phoenix]

Zitat von implementation:

Beispiel:
Angenommen du benutzt für Pfade immer Backslashes, dann ist es per se nur für Windows geeignet, wenn nicht irgendein Feature in der Bibliothek das wieder ausbügelt, denn unixoide Systeme haben eine andere Pfadsyntax.

Nungut, das ist aber mit .NET / Mono kein wirkliches problem. Man gibt URL's dort immer als URI an, und die Auflösung zur richtigen Datei wird automatisch gemacht. Genauso gibt es Environment.NewLine um je nach System den richtigen Zeilenumbruch zu bekommen. Man muss das Zeug halt nur konsequent benutzen.