ObjectPascal mit Oxygene verarbeiten

[mschaefer]

Danke! Für beide Varianten :-).

Habe da noch eine Frage: Kann das System C# und Pascal-Code gemischt einsetzen?

[mkinzler]

Zitat:

Zitat von mschaefer (Beitrag 1213716)

Danke! Für beide Varianten :-).

Habe da noch eine Frage: Kann das System C# und Pascal-Code gemischt einsetzen?

Bei Verwendung von Oxygene for .Net ja.

[Phoenix]

Jain. Innerhalb eines einzelnen Projektes: Nein.
Du kannst aber auch nicht C# und VB.NET Files im gleichen Projekt haben.

Innerhalb einer Solution aber ja, problemlos. Du kannst ein Projekt z.B. als Bibliothek in C# schreiben, ein weiteres in VB.NET, eines in F# und eines in Oxygene. Dazu brauchst Du allerdings ein Visual Studio mindestens in der Professional-Edition.

Hast Du das nicht, sondern z.B. nur ein VS-Express Edition für C#, dann klappt das nicht innerhalb der gleichen Solution. Dann kannst Du mit der C# Express deine Bibliothek bauen, und dann das Assembly aus dem Oxygene-Projekt heraus verwenden.

[mschaefer]

Ok, auch dafür erstmal Danke.

Inzwischen liegt hier auch VS-Prof. Wie das mit Delphi weitergeht, da bin ich mir im Moment nicht im klaren.

Für heute war es das :-)

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1213714)

Oxygene ist dafür entworfen, seine Business-Logik einmal zu schreiben

Jepp, dauert nur länger. Aber ist sauberer.
Delphi ist eben ein RAD-Tool, und imho eines der Besten (für diesen Zweck). Powerbuilder ist noch so ein Kandidat. Aber ist eben gefrickelt. RAD und MVVM/MVC beißt sich nun einmal.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1213747)

RAD und MVVM/MVC beißt sich nun einmal.

Ja. Deswegen rante ich ja auch so gegen FMX ;-)

Letzen Endes muss aber jeder selber entscheiden ob er mit RAD schneller am Mark ist, und ihn dann hinterher wegen der fehlenden Anwendungsarchitektur und starken Kopplung im Code die Wartungskosten auffressen, oder ob er etwas länger braucht, dafür aber eine bessere Architektur, automatisiert testbaren Code und deutlich geringere Wartungskosten hat. Zudem lassen sich bei ordentlicher Architektur neue Anforderungen schneller umsetzen bzw. wenn die Architektur doch mal nicht passt, sich diese umbauen und durch Unit- und Integrationstests garantieren, dass der Rest der Anwendung immer noch das tut, was sie soll.
Aber was quatsche ich hier um Binsenweisheiten rum...