Ziemlich genial sind dynamic Methods, damit kann man ziemlich easy Code on-the-fly erzeugen ohne den Umweg über eine dyn. Assembly gehen zu müssen. Damit lassen sich ein paar Sache ziemlich nett lösen, für die wiederholte Reflection Friemeleien schlichtweg zu lahmarchig wären.
Auf der IDE Seite kann man fullfledged RAD für "richtiges"[meta]also ohne eklige DataSets[/meta] .Net-DataBinding aufführen. Und natürlich ein XSLT Debugger, der einem ganz gut dabei unterstützt aus lahmen serverseitigen ASP.Net controls browser-seitiges XML Binding zu machen.
Sämtliche XML Sachen sind auch gehörig schneller geworden.
Die BCL wurde auch aufgestockt: Man hat nun genrische LinkedList, List, SortedDictionary, TreeSet und sogar eine generische BindingList.
Interface wie IComparable<T>, IEquatable<T>,.. ermöglichen Vergleiche in generics ohne, wie früher, Boxing und 10 Umwege in Kauf nehmen zu müsen.
Oh eins noch: calli ist nur noch doppelt so lahm wie call und callvirt dauert nur noch 2.5-mal so lange (konnte in 1.1 durchaus 5-mal so lange brauchen). Bevor das einer falsch versteht, ich meine nur den call, nicht die ganze Laufzeit einer Methode.
Ich weiß nicht was du in deinem Projekt so alles machst, aber alleine generics würden sicher den Code nicht nur reduzieren sondern ihn auch noch beschleunigen.
ADO.Net bekam die ProviderFactories, die es gegenüber Interface-basierten Löungen von 1.1 (wo bekomme ich eine Instanz der Connection her? ) wesentlich einfacher werden lässt.
2.0 is the way to go.So einfach ist das.
Mein Beileid an alle BDS User.
btw: Keine Ahnung wieoft du redist und SDK gesaugt hast um auf 380 MB zu kommen...
oh fast vergessen: Man kann nun Accessors einer Property unabhängig von ihrer Sichtbarkeit machen:
C#-Quelltext
1:
2:
3:
4:
5:
| public int Miep
{
get { return miep; }
protected set { miep = value; }
} |
Chome-Quelltext
1:
| public property Miep : Integer read fMiep protected write fMiep; |
Christian S.
Hast Recht. Ich hatte noch die Größe der Betas im Kopf, die ähnlich der des 1.1 SDKs war. 