Wer z.B. ein HttpModul in der Web.config registrieren möchte, muss immer den “Full Qualified Name” eines Types angeben. Wer mit SharePoint zutun hat, wird spätestens bei den SafeControls darauf stoßen. Da ich vor kurzem etwas gerätselt habe, wie dieser “Full Qualified Type Name” aufgebaut ist, hier die Lösung:
Am 18.10 findet in Leipzig der .NET Open Space statt. Die Registrierung wurde am 3. August geöffnet. Da die Teilnehmeranzahl bereits jetzt dem Niveau vom letzten Jahr entspricht sollte man sich bemühen, wenn man noch teilnehmen möchte.
Da diese Veranstaltung kostenlos ist, suchen wir nun verstärkt nach Sponsoren. Wer also Interesse hat mit dabei zu sein, der sollte sich noch sehr schnell registrieren! Wenn ein Unternehmen als Sponsor mit auftreten möchte, der meldet sich am besten beim Team.
Microsoft bietet ein Whitepaper zu den Azure .NET Services und ein “Identity Developer Trainings Kit” zum Download an.
Morgen trifft sich die .NET User Group Dresden in der HTW Dresden. Wer den Termin noch nicht kannte, sei hiermit herzlich eingeladen. Alle Details und die Teilnehmerliste findet man auf der Homepage.
Mono als Spieleplattform? Geht nicht? Geht doch: Sogar auf der Wii und dem iPhone über Unity3D. Erste monobasierte Spiele im AppStore bzw. überall im Handel.
Ich habe schon öfters über die Wii gesprochen und was man damit nicht alles tolles machen könnte – das letzte mal im Zusammenhang mit pptPlex.
Das hat mich als Besitzer einer Wii natürlich auch etwas neugierig gemacht. Auf der Setup Seite von dem pptPlex + Wii Eintrag steht geschrieben, wie man es zum Laufen bekommt.
Hier gesammelt nochmal alles, was ich zum erfolgreichen Verbinden brauchte:
Wie die Wiimote mit der Wii komuniziert
Die Wiimote überträgt alle Signale über Bluetooth zur Wii Konsole. Die Wii-Sensorbar besteht aus 4 Infrarot-LEDs (zwischen 940nm und 850nm), welche zur Positionsbestimmung der Wiimote dienen.
Mehr technische Details gibt es auf der Wiki-WiimoteProject.
Die Wiimote mit dem PC verbinden
Hierfür braucht man einfach einen PC/Notebook mit Bluetooth – allerdings ist nicht alles mit der Wiimote kompatibel.
Für das “synchronisieren” mit der Bluetooth-Einheit am PC/Notebook muss man während des Gerätesuchlaufes auf die Taste 1/2 drücken oder die Sync-Taste bei dem Batterien drücken – siehe hier.
Die Wiimote gibt sich als Nintendo RVL-CNT-01 Gerät aus und braucht kein PIN oder ähnliches.
Jetzt sollte die Verbindung erfolgreich verlaufen.
Eine eigene Sensorbar
Damit man nicht die Wii jedesmal mitschleppen muss und damit man eine Infrarot-Quelle hat hat man 2 Möglichkeiten:
- Kerzen (senden auch Infrarot-Licht aus)
- Selber bauen:
Auf die Signale reagieren
Jetzt brauchen wir noch entsprechende Software oder man schaut sich das .NET “SDK” dazu mal an.
Eigentlich ganz einfach 
In dem heutigen HowTo geht es um das Erstellen von eigenen .NET Events samt dem dazu gehörigen testen mit einem Unit-Test.
Was ist ein Event aus “Anfängersicht”?
Jeder der (wahrscheinlich) in einer X-beliebigen IDE für eine X-beliebige Sprache bereits irgendein Button auf ein Fenster gezogen hat, wird als Resultat dann so einen ähnlichen Code sehen:
private void button1_Click(object sender, EventArgs e)
{
}
Hier kann man nun ganz genau definieren, was passiert wenn der “button1″ geklickt wird.
Eigentlich eine tolle Geschichte
Was passiert denn technisch im Grunde genommen dahinter?
Events sind von der Idee her bereits sehr alt. Der Grundgedanke ist einfach nach dem “Hollywood-Prinzip“: Ruf nicht uns an – wir rufen dich an.
Im Code brauchen wir nicht ständig prüfen ob der Button geklickt wird oder nicht – der Button sagt uns, wann er geklickt wird.
Ohne jetzt die .NET Implementierung (also was im Framework passiert) näher untersucht zu haben, würde ich meinen, dass das Grundkonzept aus dem Observer-Pattern abgeleitet ist.
Was ist ein Event: Beispiel aus der realen Welt
Um mal ein Beispiel aus der realen Welt aufzugreifen – auch wenn dies manchmal arg abstrakt ist 
Wenn jemand ein “Bild-Zeitungs-Abo” hat, fragt der normal-deutsche-Leser auch nicht ständig den Herrn Springer ob es nun eine neue Ausgabe gibt oder nicht – er bekommt sein Exemplar automatisch sobald es gedruckt wurde.
Einsatzgebiet von Events
Sobald man irgendwelche “Prozesse” oder “Abläufe” modelliert, könnte man im Prinzip auf Events setzen – ich persönlich bin erst vor kurzem auf das Thema gekommen. Das liegt vor allem daran, dass ich bisher meistens mich mit Web-Projekten beschäftigt habe. In der ASP.NET Welt sind meiner Meinung nach Events nicht so unglaublich nützlich. Der Grund liegt auf dem, wie HTTP funktioniert:
Der Client macht eine Anfrage und der Server antwortet entsprechend. Rein theoretisch geht nun ein Ablauf los – der irgendwann beeendet ist – das “Ich-bin-fertig-mit-meiner-Aufgabe” könnte über ein Event mitgeteilt werden.
An dieser Stelle sollte der Server an den Client zurückschicken: Bin fertig. Allerdings geht dies nicht:
Im HTTP Umfeld kann der Server nicht einfach Daten zum Client schicken – der Client (Browser) muss immer erst die Anfrage stellen. Dadurch muss man auf der Clientseite (über AJAX z.B.) ein Polling durchführen. Das führt natürlich dazu, dass Events leicht nutzlos werden.
Allerdings sind sie in sämtlichen Client-Anwendungen die nicht auf HTTP beruhen äußerst nützlich
Eigene Events definieren
Dan Wahlin hat ein sehr schönes Video erstellt, in dem die Grundgedanken sehr gut vermittelt werden.
Mein Beispiel:
Wir haben eine bestimmte Anwendung, welche jeweils einen Verbindungsstatus haben kann:
Diese “ConnectionStates” in der Anwendung werden von einem “ConnectionManager” verwaltet.
Jetzt wäre es ja schön, wenn uns unser “ConnectionManager” sofort informiert, wenn sich der Status ändert.
Dazu erstmal das grobe Konstrukt unserer Klasse:
public class ConnectionManager
{
private ConnectionStates _state;
public ConnectionStates State
{
get
{
return _state;
}
set
{
_state = value;
}
}
public ConnectionManager()
{
this.State = ConnectionStates.Disconnected;
}
}
Der Anfangsstatus ist erstmal auf “Disconnected” gestellt. Der Rest sollte soweit klar sein.
Jetzt kommen wir zur eigentlichen Eventdeklaration.
Schritt 1: Delegat definieren
Als ersten Schritt schreiben wir uns ein Delegat:
public delegate void StateChangedEventHandler(object sender, StateChangedEventArgs e);
Ein Delegat darf man als eine Art “Funktionszeiger” (im Video von Dan Wahlin wird es auch als Pipe zwischen Objekten verglichen) verstehen.
Schritt 2: StateChangeEventArgs definieren
In unserem Delegat definieren wir eine Methodendeklaration die so später auch der Clientcode sieht – als EventArgs definieren wir ebenfalls unsere eigene Klasse:
public class StateChangedEventArgs : EventArgs
{
public ConnectionStates NewConnectionStates { get; set; }
}
Hier definieren wir einfach, was wir in unseren EventArgs später haben wollen – uns interessiert natürlich am meisten, was nun der neue Status ist.
Schritt 3: Event definieren
Jetzt definieren wir unser Event – an diesem können sich später die entsprechenden Clients melden:
public event StateChangedEventHandler StateChanged;
Dieses Event ist vom Typ “StateChangedEventHandler” – welches unser vorher definiertes Delegat ist.
Zwischenschritt: Der Client
Allein durch diese Definition des Events und des Delegates ist es möglich, das sich “Clientcode” an das Event dran hängt:
class Program
{
static void Main(string[] args)
{
ConnectionManager man = new ConnectionManager();
Console.WriteLine("Start state: " + man.State.ToString());
man.StateChanged += new ConnectionManager.StateChangedEventHandler(man_OnStateChanged);
man.State = ConnectionStates.Connecting;
man.State = ConnectionStates.Connected;
man.State = ConnectionStates.Disconnected;
Console.ReadLine();
}
static void man_OnStateChanged(object sender, StateChangedEventArgs e)
{
Console.WriteLine("State changed...");
Console.WriteLine("New state is: " + e.NewConnectionStates.ToString());
}
}
Die “man_OnStateChanged” Methode ist zwar definiert – allerdings rufen wir in unserem “ConnectionManager” nie das Event auf.
Schritt 4: Event in der Klasse aufrufen
In unserem Setter müssen wir natürlich das Event werfen – dies geschieht über eine weitere Methode in der Klasse. Hier mal der komplette Source Code:
public class ConnectionManager
{
private ConnectionStates _state;
public ConnectionStates State
{
get
{
return _state;
}
set
{
_state = value;
OnStateChanged();
}
}
public delegate void StateChangedEventHandler(object sender, StateChangedEventArgs e);
public event StateChangedEventHandler StateChanged;
protected void OnStateChanged()
{
if (StateChanged != null)
{
StateChangedEventArgs args = new StateChangedEventArgs();
args.NewConnectionStates = this.State;
StateChanged(this, args);
}
}
public ConnectionManager()
{
this.State = ConnectionStates.Disconnected;
}
}
Bei jedem setzen eines ConnectionStates wird die “OnStateChanged” Methode aufgerufen – diese ist nur intern erreichbar (”protected”) bzw. von vererbten Klassen.
Diese Methode prüft, ob das “StateChanged” Event irgendwelche Beobachter hat – if(StateChanged != null).
Falls irgendwer im Clientcode sich an das Event angehangen hat, wird das Event mit unseren EventArgs geworfen.
Es klingt komplizierter als es ist
Da ich ebenfalls “neu” darin bin, musste ich mich ebenfalls erst mal in das Einarbeiten. Um es mal in kurzen Worten zu formulieren (soweit mein Verständnis richtig ist):
Resultat
In der Clientanwendung (die Consolen-Applikation) wird jedesmal die Ausgabe gemacht, sobald sich der Status ändert. Ohne jedes mal eine extra Methode aufzurufen oder die Ausgabe an den Manager zu ketten:
Unit-Tests: Wie teste ich Events?
Events kann man über eine nette C# 2.0 Sache testen: ein anonyme delegate. Den Trick habe ich bei Phil Haack gefunden.
[TestMethod]
public void ConnectionManager_Raise_StateChanged_Event()
{
ConnectionManager man = new ConnectionManager();
Assert.AreEqual(ConnectionStates.Disconnected, man.State);
bool eventRaised = false;
man.StateChanged += delegate(object sender, StateChangedEventArgs args)
{
eventRaised = true;
};
man.State = ConnectionStates.Connecting;
Assert.IsTrue(eventRaised);
}
In diesm Test lege ich einen bool “eventRaised” an – sobald das Event geworfen wird, wird ein anonymes delegat aufgerufen (man spart sich hier die zweite Methode) und ich setzt einfach diesen boolean auf “true”.
Sehr einfach und genial um zu testen, ob das Event wie gehofft auch geworfen wird
Immmer wenn ich eine Xml Datei lesen oder schreiben will fange ich wieder an das Code-Snippet dafür zu suchen und an meine Objekttypen anzupassen. Also habe ich mir jetzt mal eine generische Version geschrieben. Das T steht dabei für den noch unbekannten Typ der erst zur Laufzeit übergeben wir.
public static void Save<T>(String path, T obj)
{
XmlSerializer Serializer = new XmlSerializer(typeof(T));
FileStream Stream = new FileStream(path, FileMode.Create);
Serializer.Serialize(Stream, obj);
Stream.Close();
}
public static T Load<T>(String path)
{
XmlSerializer Serializer = new XmlSerializer(typeof(T));
StreamReader Stream = new StreamReader(path);
T myObject = (T)Serializer.Deserialize(Stream);
Stream.Close();
return myObject;
}
Der Zugriff erfolgt so:
// Daten
String TestString = "Hallo Xml Welt";
//schreiben..
Save<String>("C:\\test.xml", TestString);
//und lesen
Debug.WriteLine(Load<String>("C:\\test.xml"));
Ich hatte ver kurzem das Problem das ich auf eine XML Datei in meinem Projekt zugreifen musste aber den genauen Pfad nicht kannte. Das erzeugen eines dynamischen Pfades per “AppDomain.CurrentDomain.BaseDirectory” war nicht möglich da ich mit Usercontrols arbeitete und so nur den Pfad der Datei bekam die mein Uercontrol einbindet.
Gelöst habe ich das Problem in dem ich über den Namespace auf die XML Datei zugegriffen habe:
// XmlResource = Namespace + Dateiname
string XmlResource = "CodeInside.WebApp." + "Daten.xml";
using (Stream FileStream = System.Reflection.Assembly.
GetExecutingAssembly().GetManifestResourceStream(XmlResource))
{
XmlSerializer Ser = new XmlSerializer(typeof(List));
StreamReader Sr = new StreamReader(FileStream );
List Data = (List)Ser.Deserialize(Sr);
Sr.Close();
}
Damit man auf die Datei auch zugreifen kann muss man in den Eigeschaften der Datei das Feld “Build Action” auf “Embedded Resource” stellen.
Die .Net User Group aus Dortmund(www.Do-DotNet.de) hat ein kleines Tool veröffentlicht welches man einsetzen kann um gedrückte Tasten während einer Präsentation, Screencast… zu visualisieren. Dank dieses Tools können die Zuschauer nachvollziehen welche Tastenkombos benutzt wurden. Das Tool gibt’s unter:
http://www.do-dotnet.de/front_content.php?idcat=7&idart=21
Der Key Presenter und viele andere Themen werden am 25.4 beim Treffen der Usergroup vorgestellt.
Wenn man größere Datenmegen auf einer ASP Seite anzeigen oder per Webservice übertragen möchte, kann man die Übertragungsdauer durch Komprimierung erheblich reduzieren (je nach Inhalt schrumpft die Datenmenge auf ca. 1/4).
Eine ausführliche Anleitung wie man die Komprimierung (gzip und deflate) ohne großen Aufwand und Änderungen am Code einrichtet findet ihr hier.
Hier die Kurzanleitung:
1. Füge diese Datei in dein Projekt ein.
2. Webseite neu bauen.
3. Fertig
Das Thema ist eigentlich schon alt – wie kann man .NET Methoden aus Javascript aufrufen. Mit ASMX Webservices ging dies recht einfach – siehe HowTo – doch geht das auch mit WCF?
Seit .NET 3.5 und Visual Studio 2008 strahlte mich dieses Itemtemplate an:
“AJAX-enabled WCF Service” klingt schonmal gut.
Daraus wird dann sowas (ich hab die Standardmethode mal abgewandelt) :
using System; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Activation; using System.ServiceModel.Web; [ServiceContract(Namespace = "")] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class Service { // Add [WebGet] attribute to use HTTP GET [OperationContract] public DateTime GetDateTime() { return DateTime.Now; } // Add more operations here and mark them with [OperationContract] }
Wie üblich, muss man den ScriptManager diesen Service (mit der .svc Endung) noch registrieren:
<asp:ScriptManager ID="ScriptManager1" runat="server"> <Services> <asp:ServiceReference Path="~/Service.svc" /> </Services> </asp:ScriptManager>
Wenn man dies jetzt einfach mal so ausführt, bekommt man folgendes (im Firebug) zu sehen:
Schauen wir uns das Ergebnis jetzt mal per Javascript an:
Eigentlich ist es genau dasselbe wie bei den “alten” ASMX Webservices – nur diesmal mit WCF.
Doch im Detail gibt es Unterschiede
Um dies deutlich zu machen, folgender Aufbau der Website:
Ich habe einmal einen WCF und einen ASMX Webservice erstellt, mit folgenden Methoden:
- GetDateTime: Gibt ein DateTime Objekt zurück
- GetComplexOne: Gibt einen eigenen Objekttyp “Complex” zurück
- GetComplexList: Gibt eine Collection an “Complex” Typen zurück.
Beschreibung von eigenen Objekttyp “Complex”
“GetList” und “GetOne” sind beide statisch. “Number” ist vom Typ integer und die anderen beiden sind Strings.
Erstellung des ASMX Webservice
Der ASMX Webservice ist nicht weiter schwierig:
using System; using System.Collections; using System.Linq; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Linq; using System.Collections.Generic; /// <summary> /// Summary description for WebService /// </summary> [WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] // To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line. [System.Web.Script.Services.ScriptService] public class WebService : System.Web.Services.WebService { public WebService () { } [WebMethod] public DateTime GetDateTime() { return DateTime.Now; } [WebMethod] public ComplexType GetComplexOne() { return ComplexType.GetOne(); } [WebMethod] public List<ComplexType> GetComplexList() { return ComplexType.GetList(); } }
Wichtige Attribute sind hier das für die Ajax-Integration wichtige “ScriptServiceAttribut“, sowie das “WebMethodAttribut“. Wer mehr Infos möchte, dem sei dieser MSDN Artikel ans Herz gelegt.
Im Javascript werden diese Webmethoden in solch einen Wrapper gesetzt:
Erstellung des WCF Services
Der WCF Service ist ähnlich vom Aufbau, allerdings sind andere Attribute und Klassen im Gebrauch:
using System; using System.Linq; using System.Runtime.Serialization; using System.ServiceModel; using System.ServiceModel.Activation; using System.ServiceModel.Web; using System.ServiceModel.Description; using System.Collections.Generic; [ServiceContract(Namespace = "")] [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class Service { // Add [WebGet] attribute to use HTTP GET [OperationContract] public DateTime GetDateTime() { return DateTime.Now; } [OperationContract] public ComplexType GetComplexOne() { return ComplexType.GetOne(); } [OperationContract] public List<ComplexType> GetComplexList() { return ComplexType.GetList(); } // Add more operations here and mark them with [OperationContract] }
Das wichtigste Attribut für den JSON Webserive ist das “AspNetCompatibilityRequirementsAttribute” und dann für WCF typisch das “OperationContractAttribute“.
Wenn man das nun so kompiliert und die beiden Services in den ScriptManager einbindet, bekommen wir einen Fehler in unserem WCF Service!
Den “ComplexType” für WCF zugänglich machen
WCF serializiert nur das, was konfiguriert wurde (um es mal einfach auszudrücken). Dafür müssen über dem Typen ein “DataContractAttribute” gesetzt werden und über jeden Member ein “DataMemberAttribute“.
Sobald dies gemacht wurde, sieht man im Javascript folgendes:
Die serializierten Objekte sind identisch mit der ASMX Variante.
Mehr zum Thema JSON Serializierung: Stand-Alone JSON Serialization.
Zwischenfazit
Läuft schonmal ganz gut und bis auf die Sache mit dem “DataContract/MemberAttributen” sind kaum Unterschiede. Wenn man etwas mehr ins Detail geht, findet man allerdings noch das ein oder andere, was anders ist:
Unterschiede Namespaces:
Wenn man um die ASMX “WebService” Klasse ein Namespace “WebServiceNamespace” zieht, wird aus dem Javascript Wrapper folgendes:
Wenn man um den WCF Service einen Namespace zieht, passiert erstmal garnix – warum weiß ich spontan auch leider nicht. Um jedoch den selben Effekt zu erzielen wie bei der ASMX Variante muss man im “ServiceContractAttribute” einen Namespace setzen:
[ServiceContract(Namespace = "ServiceNamespace")]
Unterschiede HttpContext / ASP.NET Integration:
In einem WCF Service kann man nicht auf HttpContext zugreifen, sondern auf einen OperationContext. Dies und mehr ist auf der MSDN ganz gut beschrieben:
Weitere Infos & Fazit:
Auf der MSDN ist noch ein weiteres einfaches Beispiel zu finden.
Hier sind auch noch zwei andere Blogposts zu dem Thema:
WCF Serivces sind eine mächtige Alternative zu den ASMX Webservices und die Integration in eine AJAX Anwendung ist kaum schwieriger als die ASMX Variante – wenn man die Möglichkeit hat und etwas rumexperimentieren möchte, der sollte dies wahrnehmen. Hier noch der Democode:
Die Schweizer “bbv” bietet nun auch ein .NET 3.5 Poster kostenlos an – einfach Adresse angeben und wenig später bekommt man es zugeschickt (aus der Schweiz dauert es natürlich etwas ).
Microsoft selbst bietet natürlich auch ein schickes Poster seit geraumer Zeit an – zum selber plotten.
Der erste Tag der VSone ist vorbei und ich werde einfach mal ein kurzes Review geben. Vom organisatorischen her, ist es bis jetzt sehr gut verlaufen. Im großen IMAX zu sitzen, kostenlos Popcorn zu bekommen und dabei auf der großen Leinwand eine WPF Entwicklung zu sehen, ist schon sehr cool – auch wenn das für Normalsterbliche sicherlich ein seltsamer Anblick ist
Die Verpflegung ist spitze (und kostenlos) und die Leute sind allesamt recht nett, auch wenn ich teilweise den Altersdurchschnitt etwas senke (wobei Andere ihn wiederrum steigern).
Die Sprecher sind allesamt sehr nett und kann man auch mal leicht etwas über sein Kummer und Leid erzählen.
Nun kurz zu den Themen, die ich heute besucht hatte – es gab pro Track noch mehrere andere Vorträge parallel – interessierte sollten die Blogs von den Sprechern im Auge behalten:
Erstes Vortrag: XAML, WPF & Expression Blend
Ein sehr praktischer Vortrag von Markus Egger – wie frischt man eine einfache “UI” mit WPF auf. Ausführlich wurde dort Expression Blend vorgestellt, was ich zwar schon kannte, allerdings waren mir einige Funktionen noch nicht bekannt. Wie schnell man aus einer langweiligen UI eine schicke Anwendung bastelt (natürlich nur mit dem “Glass Effekt”, hat mich doch etwas angespornt, dort mehr Zeit zu investieren.
Eine andere Sache, die mir dabei ins Auge fiel: In Expression Blend gibt es eine coole “Commandsuche”, man konnte die Menüs ähnlich wie in Vista einfach so durchsuchen und es wurde jeweils das richtige angezeigt – bin mal gespannt, wann das in Office zu finden ist.
Nächster Vortrag: WPF Datenbindung
Ebenfalls sehr praxisbezogen – was versteht man unter Datenbindung, was kann diese und wie sieht das aus. Was spielen “Dependancy Properties” und was sind die “INotification…” Schnittstellen (z.B. INotifyPropertyChanged) – dies waren unter anderem Hauptthemen. Vorgetragen war dies von Christian Nagel. Zusammen mit dem ersten Vortrag, in dem es mehr um das Design ging, hat dieser Vortrag mich besonders als Entwickler begeistert – und wird sicherlich mal den ein oder anderen Blogpost Wert sein.
Nächster Vortrag: Microsoft Sync Framework
Das Microsoft Sync Framework ist noch nicht allzu alt, jedoch bereits in VS 2008 zu finden. In dem Vortrag von Alexander Duggleby ging es nur um dieses Thema. Mich persönlich hat dieses Thema doch recht interessiert und war auch gut vorgetragen. An praktischen Anwendungsfällen fehlt es mir momentan noch, vor allem da mir es noch nicht 100% klar war, wie man die einzelnen Provider (es gibt von MS einige wenige vorgefertige Provider, z.B. einen Fileprovider, um Files zu synchronisieren) einsetzt – aber man stelle sich folgendes vor: Ich lege Bilder in meinen “Eigene Bilder” Ordner und es wird auf mein Flickr, MySpace etc. Profil geladen – und wenn ich mich auf einen anderen Rechner einlogge, kann dies ebenfalls wieder syncronisiert werden. Theoretisch sollte dies gehen. Das wäre mal ein nettes Projekt
Nächster Vortrag: Parallele Programmierung
Zum Anfang war ich hier recht skeptisch, weil viel Zeit mit “nicht .NET Themen” verging – jedoch ergab es hinterher ein sehr rundes Bild, vorgetragen von Bernd Marquardt. Es standen 3 Hauptthemen an – “OpenMP“, was für C++ oder Fortran gedacht ist, “SIMD“, welches ein anderes Modell fährt als “OpenMP” und “LINQ Parallel“, was direkt für C#/.NET momentan als CTP verfügbar ist.
Grundgedanke von “OpenMP”: Leicht mehrere Prozessoren nutzen. Bei einer Schleife von “0-999″ macht Prozessor 1 “0-499″ und Prozessor 2 “500-999″. Dies wurde recht anschaulich demonstriert und vor allen ist der gebrauch recht einfach.
Als zweites kam “SIMD”, was mehr auf die Hardware geht und Prozessoreigenschaften nutzt. Es werden Daten in einem Array in einem Schritt bearbeitet – anstatt einzeln. Das ist zwar auch schick, weil Threads nicht eingesetzt werden, ist aber noch mehr an die Prozessoren gebunden (und der Aufruf ist hässlich) das geht beides nur in C++ (oder OpenMP in managed C++).
“Parallel LINQ” geht einen ähnlichen Weg wie “OpenMP”, allerdings zum Teil mit einem eigenen Syntax. Primär werden hier anonyme Methoden genutzt und wer Lamda Expressions verstanden hat, der kann hier einiges an Performance rausholen. Allerdings momentan alles alpha, aber das ist sicherlich in nächster Zeit ein sehr wichtiges Thema.
Nächster Vortrag: Was kommt nach ASP.NET?
Ein sehr humorvoller Vortrag von Hannes Preishuber. Auch wenn er versprochen hat, dass man nichts davon mitnimmt, hab ich doch die ein oder andere Sache aufgeschnappt. Mir waren die ASP.NET Futures, Silverlight, ASP.NET 3.5 Extensions usw. zwar schon ein begriff, allerdings hatte ich nie das Media Control ausprobiert oder Dynamic Data Pages ausprobiert (was sehr cool ist) und auch LINQ to SQL nutzt.
Letzter Vortrag für heute: LINQ to SQL
Christoph Wille stellt LINQ to SQL vor. Zwar hatte ich selber damit schon rumgespielt, allerdings war es interessant zu wissen, wo bestimmte Sachen “schwierig” umzusetzen sind oder schlicht und einfach langsam. Als generellen Tipp habe ich mitgenommen, den SQL Server Profiler laufen zu lassen, damit man sieht, was LINQ eigentlich am SQL Server veranstaltet. Den Blog von Scott Guthrie und Mike Toulty sollte man zudem ebenfalls besuchen. Morgen (oder heute wenn sie diesen Post lesen werden), wird das ADO.NET Entity Framework vorgestellt – und die Unterschiede zu LINQ to SQL ebenfalls dargestellt.
Einige Stichpunkte noch kurz am Rande erwähnt: Die Integration von Stored Procedures (gibt auf dem Blog von Scott und Mike noch wesentlich mehr Informationen), “CompiledQuerys” für performance Gewinn, das nachträgliche Laden von Kindelementen und die damit verbundenen Probleme (DataLoad Options erlaubt nur die nächste Ebene – man kann wohl keine 2 Ebenen übergehen – wenn man danach sucht, findet man was ich meine ).
Zwischenfazit
Sehr schicke Veranstaltung.Ich werde in den nächsten Tagen/Wochen die Themen zum großen Teil aufgreifen.
Den Tag zwei werde ich sicherlich auch noch niederschreiben
Ich hab gerade was recht witziges auf Coding4Fun gefunden: Wii Drum Kit.
So sieht das ganze aus:
Sehr schick muss ich sagen – ich glaub meine Wii sollte ich auch mal zum Experimentieren nehmen
Deutsch
Englisch
