Zitat von
Christian S.:
Zitat von
Jelly:
Auf den Delphi Tagen wurde mal quer durch den Raum gefragt, wer von den Anwesenden aktiv .NET Applikationen schreibt. Von den 250 Teilnehmern waren das vielleicht mal gerade 10.
Ohne mich am Rest der Diskussion beteiligen zu wollen (die gab es schon zu oft, als das mich das noch reizt), das ist nicht sehr repräsentativ. Mit Delphi kann man nicht soooooo toll .NET entwickeln (alleine schon, weil kein .NET 2.0 unterstützt wird), da wundert mich die geringe Rate nicht.
Der Hauptgrund wird die doch sehr nette Art sein, durch die Delphi OO wurde. Delphi wird in den Borland NGs nicht ganz ohne Grund als einzige "native c#-like language" bezeichnet.
Die
VCL mag ein anderer Grund sein. Sie ermöglicht zu einem gewissen Grad ähnlich produktiv zu entwickeln wie es mit .Net möglich ist.
Auf den ersten Blick sehen es viele nicht ein, einen zweiten Blick zu riskieren.
Noch ein Grund dürfte Delphi.Net ein, welches soviele versteckte Quirks enthält um unter .Net noch ein D32-Verhalten vorzutäuschen. Da die Sprache nicht wirklich an .Net angepasst wurde stösst man sich oft die ellbogen an den neuen Geflogenheiten in dieser neuen Welt.
Wer .Net mit D.Net kennenlernt dürfte also noch ein paar willkommene Gründe vorfinden, warum er keinen 3. Blick riskieren will.
Für mich bedeutet .Net hauptsächlich GoodBye Units, Good Bye DCUs und eine riesige in sich konsistente Klassenbibliothek.
Letztlich gab es hier einen Thread über den schnellsten MD5 Algo. Nunja, der in System.Security.Cryptography ist sackschnell, genau wie Sha, AES, Rinjdael und Co.
Für native Spielereien nehme ich gerne Alzis Hashlisten, in .Net habe ich generische Dictionaries, SortedDictionaries, TreeSets,...
Alle implementieren Interfaces wie IDictionary<K, T>, so dass auch eine eigene Implementierung mit den restlichen Klassen kompatibel bleibt.
Wo wir bei Interfaces sind: .Net ist von vorne bis hinten interfacebasiert
IEnumerable ermöglicht foreach/for in, zusammen mit IList und IBindingList sollte sich das Interface aber schon rumgesprochen haben...
Es gibt aber mehr:
Du nimmst eine bestehende Klasse, verpasst ihr IComponent und kannst sie auf den Designer ziehen. (WinForm, WebForm, Service, WebService und Component)
Du implmentierst IListSource und du kannst sie als DatenQuelle im Designer an Controls binden. Du implementierst ITypedList und hast 100% Kontrolle was wie gebunden werden kann[1].
IBindableComponent lässt dich Daten an Properties deiner Klasse binden...
IEditableObject lässt dich darauf reagieren wenn der User in einem an deine Property gebundenen Control Esc drückt oder die in SWF integrierte Validierung fehlschlägt.
Zu D32 konnte ich mich nie mit dem
DB-Aware Dingsens anfreunden, DataBinding in .Net möchte ich nicht mehr missen.
Kurz gesagt: Es ist einfach ungeheuer mächtig.
Bei weiteren Fragen konsultieren sie einfach ihre lokale .Net
SDK Doku.
Ich bin echt froh, dass ich mich damals so dermaßen über D8 geärgert habe[2].
Wäre es benutzbar gewesen, hätte ich .Net wohl nie _richtig_ kennen und schätzen gelernt...
[1]auf die Art übersetzt z.B. ein DataSet den object array an Daten in einer DataRow in Properties, die man irgendworan binden kann.
[2]Ich war sooo bescheuert und hatte ein Upgrade von D7Pro auf D8Arch gekauft
Thx for the Road show