in

yellow-rainbird.de

Das Staunen ist der Anfang der Erkenntnis: .NET kann's!

Rainbird´s Blog

XING Profil von Rainbird öffnen
  • Zyan 2.0

    Die zweite Version meines Kommunikationsframeworks Zyan ist draußen. Als wichtigste Neuerungen gib´s verteilte LINQ-Unterstützung und bi-direktionale TCP-Kommunkation. Ein kurzer Überblick mit Beispiel-Codesnippets findet sich unter http://zyan.codeplex.com/wikipage?title=Was%20ist%20neu%20in%20Zyan%202.0%3f&referringTitle=Deutsche%20Dokumentation.

    Zyan 2.0 läuft auch problemlos in der Cloud. Momentan läuft eine auf Microsoft Azure gehostete Version des Zyan-MiniChat-Beispiels (Order examples\Zyan.Examples.MiniChat im Repository). Einfach mal ausprobieren, mit dem MiniChat-Client (aus der Beispiel-Anwendung). Als Server-URL tcpex://ZyanMiniChat.cloudapp.net:9010/MiniChat auswählen. Das Beispiel läuft auf einem Azure-Testaccount, der nach Ablauf der kostenlosen Nutzungsdauer wieder gelöscht werden wird.

    Ein Snippet, wie man die eigene Zyan-Anwendung mit wenigen Zeilen Code in Azure laufen lassen kann, gibt´s hier: http://zyan.codeplex.com/discussions/259397.

    Für die schnelle und einfache Integration in eigene Projekte, ist Zyan 2.0 nun auch als NuGet Paket verfügbar: http://nuget.org/List/Packages/Zyan.

    Ich freue mich über Feedback und Fragen zu Zyan 2.0. Bitte das Zyan-Diskussionsforum benutzen: http://zyan.codeplex.com/discussions.

    Eingetragen Jun 14 2011, 11:28 von Rainbird mit no comments
    Abgelegt unter: , , , , , ,
  • Zyan 1.0 ist fertig!

    Nach guten drei Monaten steht das fertige Kommunikationsframework Zyan, in der Version 1.0, zum Download bereit.

    Zyan ist für alle interessant, die verteilte .NET-Anwendungen entwicklen oder erst noch entwicklen wollen. Dabei spiel es keine Rolle, ob im LAN oder übers Internet kommuniziert werden soll. Der große Unterschied zu den üblichen Verdächtigen (WCF, ASP.NET Webservices, Sockets, .NET Remoting) liegt in der Einfachheit. Diese Einfachheit lässt sich mit folgenden Stichpunkten beschreiben:

    • Keine Konfigurationsdateien!
    • Klassen müssen nicht von einer speziellen Basisklasse (wie z.B. MarshalByRefObj) abgeleitet werden, um übers Netzwerk aufgerufen werden zu können
    • Keine deklarativen Attribute nötig (wie z.B. bei WCF üblich)
    • Standard-Konfiguration kommt auf Server- und Clientseite jeweils mit einem Dreizeiler aus

    Wie einfach man mit Zyan verteilte Anwendungen entwickeln kann, zeigt folgendes Einstiegsbeispiel: Erste Schritte mit Zyan 

    Aber Zyan ist nicht nur einfach, sondern auch leicht erweiterbar und vielseitig. Für die meisten Probleme, die Entwickler verteilter Anwendungen haben, bringt Zyan fertige Komponenten mit. Wenn diese für den eigenen Anwendungsfall doch nicht passen, kann man. mit wenig Aufwand, eigene Erweiterungen für Zyan schreiben. Folgende Features sind in Zyan enthalten:

    • Systemanforderungen
      • Auch auf dem Server nur .NET 3.5 Client Profile nötig
      • Läuft auch unter mono 
    • Protokolle
      • Schnelle binäre TCP-Kommunikation
      • Kommunikation über HTTP mit binärer Serialisierung
      • Interprozesskommunikation über Named Pipes
      • Schnittstellen zur Erweiterung des Systems um eigene Protokolle 
    • Authentifizierung
      • Authentifizierung mit Benutzername und Kennwort eines Windows-Benutzers des Servers
      • Single-Sign-On Authentifizierung mit Windows-Benutzer über SSPI
      • IAuthenticationProvider-Schnittstelle zur Anbindung benutzerdefinierter Authentifizierungssysteme
    • Kommunikationssicherheit
      • Verschlüsselte und Signierte Netzwerkkommunikation mit Kerberos oder NTLM in Verbindung mit Active Directory
      • Verschlüsselte Netzwerkkommunikation mit symmetrisch verschlüsselten asymetrischen Schlüsseln (keine Zertifikate nötig!)
    • Sitzungsverwaltung
      • Schnelle In-Memory Sitzungen
      • oder skalierbare SQL Server gespeicherte Sitzungen (Selbe Sitzung über mehrere Applikationsserver hinweg möglich)
      • Unterstützung für Sitzungsvariablen
      • ISessionManager-Schnittstelle zur Anbindung einer benutzerdefinierten Sitzungsverwaltung
    • Komponentenfeatures
      • Verwaltung der entfernt zugreifbaren Komponenten in Komponenten-Katalogen
      • Vielfältige Möglichkeiten zur Objektaktivierung (automatisch, Singleton, über eigene Factory)
      • Intuitive Unterstützung von verteilten Event Based Components (Verteiltes EBC-Beispiel mit Zyan)

    Hinweis:
    Zyan hat nichts mit Webservices oder SOAP oder dergleichen am Hut. Zyan ist nur für Kommunikation zwischen .NET-Komponenten gedacht. Für die Kommunikation mit anderen Plattformen (z.B. Java) bietet Zyan derzeit keine Unterstützung an. 

    Zyan kostet übrigens nix und auch der Quellcode ist frei verfügbar. Ihr könnt damit alles treiben, was Ihr wollt (Zyan steht unter MIT Lizenz).

    Für Fragen zum Zyan Projekt stehe ich gerne zur Verfügung. Hier gehts zum Zyan-Diskussionsforum: http://zyan.codeplex.com/discussions
    Ich freue mich übrigens über jeden gemeldeten Bug: Zyan Issue Tracking

    - Hagen Siegel

  • entrastructure

    Es ist soweit! Meine Gedanken zu einer freien Plattform für Business Software nehmen Form an.
    Allgemeine Frameworks wie z.B. das .NET Framework sind zwar cool, bieten aber keine vollständige Infrastruktur für Geschäftsanwendungen. Zu vieles ist da noch Handarbeit.
    Fertige ERP/CRM/SCM-Systeme sind zwar anpassbar, bieten meistens aber zu wenige Möglichkeiten, um eigene Erweiterungen zu schreiben. Im .NET-Bereich sieht es mit ERP & Co. eh sehr mau aus. Noch nicht einmal Microsoft kann ein System anbieten, welches wirklich mit .NET-Technologie aufgebaut ist.

    Abhilfe könnte da entrastrucure (free enterprise Infrastructure) schaffen. Es handelt sich dabei um ein freies Software-Projekt, welches nicht etwa ein neues ERP-System wird, sondern eine Plattform für solche und änliche Anwendungen. Die Entwicklung hat gerade erst begonnen!

    Wer sich dafür interessiert, findet alle Infos inkl. Source Code unter http://entrastructure.codeplex.com.

     

    Eingetragen Nov 04 2009, 01:14 von Rainbird mit 1 comment(s)
    Abgelegt unter: , , , ,
  • Bug in Visual Studio 2008: n-Tier-DataSets funktionieren nicht mit Projektmappenordnern

    Erst kürzlich habe ich Microsoft noch gelobt, dass sie in Visual Studio 2008 eine Möglichkeit geschaffen haben, TableAdapter von der DataSet-Definition zu trennen und beides in getrennten Projekten unterzubringen. Nun muss ich (nach einem freundlichen Hinweis aus der myCSharp.de-Community) dieses Lob leider wieder nach unten korrigieren. Das Ganze funktioniert nämlich nicht, wenn die Projekte in Projektmappen-Ordnern liegen. Sad

    Details zu diesem Bug und der aktuelle Status sind hier nachzulesen: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=378368

    Eingetragen Jan 20 2009, 08:41 von Rainbird mit no comments
    Abgelegt unter: ,
  • Eine kleine Geschichte zum Thema RowState und OR-Mapper

    Zu Zeiten von .NET 1.x und 2.0 war die Welt noch einfach. Frei Haus gab es genau Eine Datenzugriffstechnologie, nämlich ADO.NET. Die gibt es natürlich immernoch, aber mittlerweile sind noch Linq2SQL und das Entity Framework dazugekommen. Die Beiden Neuen sind "echte" OR-Mapper, da sie Resultsets in Form von herkömmlichen .NET Objekten ausspucken. Das Entity Framework arbeitet sogar mit einer eingezogenen Abstraktionsebene und verspricht Datenzugriffslogik unabhängig vom RDBMS implementieren zu können. SQL ist out, Linq ist in! Visual Studio rundet das Ganze mit komfortablen Designern und Assistenten ab. Auch die SOAP-Freunde machen die neuen Datenschaufler glücklich, müssen sie sich doch nicht mehr mit XML-Serialisierung von properitären DataSets herumschlagen, die alles andere als interoperabel sind. Man kann also durchaus sagen: Das lange warten auf die OR-Mapping-Lösung von Microsoft hat sich gelohnt. Viele Probleme können mit den neuen Datenzugriffstechnologieen elegant gelöst werden.

    Ganz so rosarot ist die Welt dann aber doch nicht. Eine Sache stößt mir sehr bitter auf, wenn ich z.B. mit dem Entity Framework arbeite: Es gibt keinen RowState!

    Im guten alten ADO.NET ist RowState der Name einer Eigenschaft der Klasse DataRow. Eine DataRow beschreibt einen einzelnen Datensatz, der von einer Datenquelle abgerufen wurde und innerhalb einer DataTable lokal im Arbeitsspeicher liegt. Aber das ist wohl den meisten bekannt. Zurück zum RowState. Der RowState gibt an, ob die DataRow geändert, gelöscht, neuangelegt oder unverändert ist. Man kann deshalb auch sagen: Eine DataTable weiß, welche ihrer DataRows, geändert, gelöscht oder neuangelegt sind. Das ist sehr nützlich. Wenn ich z.B. eine DataTable an ein DataGridView (Windows.Forms) gebunden habe und dort als Benutzer einer Zeile lösche, ist diese Zeile in der DataTable nicht verloren, sondern der RowState wird auf "Gelöscht" (deleted) gesetzt. Wenn ich im selben DataGridView nun eine neue Zeile eingebe, erhält die dadurch erzeugte DataRow den RowState "Neuangelegt" (added). Ändere ich einen Wert in einer vorhanden Zeile, hat diese danach logischerweise den RowState "Geändert" (modified). Die DataRow weiß aber noch mehr über sich selbst. Sie kennt nicht nur ihren aktuellen Zustand, sondern merkt sich auch die Originalwerte (also z.B. vor der Änderung durch den Benutzer). Das ermöglicht es wiederum durch einfaches aufrufen der RejectChanges-Methode an der DataTable, alles sofort Rückgängig zu machen. Die neuangelegte Zeile verschwindet wieder, die Gelöschte taucht wieder auf und die die Geänderte hat auch wieder ihre alten Werte. "Na und? Das ist doch alles ein alter Hut. Das ist doch allgemein bekannt!" werden jetzt einige denken. Ich stimme zu. Es ist ein alter Hut. Das gab es auch schon alles bei Classic ADO. Also ist es nach so vielen Jahren doch eine Selbstverständlichkeit.

    Jetzt aber die große Frage: Wie mache ich das, wenn ich einen OR-Mapper benutze? Platte Objekte haben keinen RowState! Sie wissen nicht, ob sie gelöscht oder neuangelegt wurden. Sie wissen auch nicht, ob sie geändert wurden. Noch nicht mal ihre alten Werte vor der Änderung können sie sich merken. Wenn es die Objekte aber selber nicht können, muss es jemand Anderes für sie machen. Genau! Die OR-Mapping-Infrastruktur. Die wischt unaufgefordert jede kleine Träne von unseren Wangen. Beim Entity Framework kümmert sich der ObjectContext um diese RowState-Angelegenheiten. Als aufmerksamer Kontext kennt er alle Objekte, die er erzeugt hat beim Namen und führt über jedes Einzelne genau Protokoll. Das funktioniert auch super. Aber was ist mit der RejectChanges-Methode? Dafür gibt es leider beim DataContext keine Entsprechung. Wenn ich meine Änderungen verwerfen will, muss ich entweder vorher eine komplette Kopie der Objektliste erstellen und diese für eine mögliche Wiederherstellung des Originalzustandes im Speicher halten. Oder ich rufe einfach die Daten nochmal vom Datenbank-Server ab. Letzteres ist verglichen mit meiner RejectChanges-Lösung aber sehr ressourcenfressend. Scheidet damit aus. Ersteres ist Umständlich und erfordert einiges an Zusatzcode (Die Sicherheitskopie der Objektliste muss dann ja dem ObjectContext erst wieder beigebracht werden). Wie sieht es mit dem DataBinding in meinem Windows.Forms-Formular aus? Ähm... Genau! Auch da muss ich rumfummeln, da meine Controls an die alte Objektliste aber nicht an die Sicherheitskopie gebunden sind. Wieder muss ich Code schreiben, um das in den Griff zu bekommen. Aber Linq und die abstrakte Modellierung sind so toll, dass ich das jetzt mal noch durchgehen lasse.

    Dass der ObjectContext den RowState-Job übernommen hat, wäre ja okay. Aber was passiert, wenn ich dahin gehe, wo ich den ObjectContext nicht mitnehmen kann? Wenn ich Resultsets über Prozess- oder gar Maschinengrenzen hinweg übertragen muss? Ich denke da z.B. an eine verteilte Anwendung mit schönen, neuen, tollen WCF-Diensten. Aber auch da kann ich erstmal aufatmen, denn der ObjectContext kann auch loslassen. Objekte können nämlich vom Kontext "detached" (getrennet) und "attached" (angefügt) werden. Die Vorgehensweise ist damit - auf den Ersten Blick - ähnlich wie bei meinen ADO.NET-DataSets:

    • WCF-Dienstseitig Daten von Datenquelle abrufen (Als Objektliste)
    • Objektliste detachen
    • Objektliste serialisieren und zum Client überragen
    • Auf dem Client mit den Objekten arbeiten
    • Ggf. geänderte Objektliste serialisieren und zurück zum Server übertragen, um die Änderungen zu persistieren
    • Ojektliste attachen
    • Änderungen Persistieren

    Klingt gut, nicht? Aber leider nur in der Theorie. Was passiert denn, wenn ich auf meinem Client eine Zeile in einem DataGridView lösche, welches an die Objektliste gebunden ist, die ich vorher vom WCF-Dienst abgerufen habe? Ganz klar, das DataBinding entfernt das Objekt aus der Auflistung. Nur ist diesmal kein ObjectContext da, der Protokoll führt. Angenommen mein DataGridView zeigt gerade zehn Zeilen an und ich lösche davon drei. Anschließend klicke ich auf Speichern. Wie soll der Server aber nun wissen, welche Datensätze er in der Datenbank löschen muss? Der ObjectContext weiss es nicht, da die betroffene Objektliste zum Löschzeitpunkt detatched war und außerdem auf einem ganz anderen Computer gelaufen ist. Ups! Jetzt fängt es an weh zu tun, denn ich muss mich auf dem Client selber darum kümmern, dass ausstehende Löschungen protokolliert werden. Außerdem muss das selbstgebastelte Löschprotokoll auch noch an den Server geschickt werden. Und zwar zusammen im selben Dienstaufruf, der auch neue und geänderte Datensätze persistiert, denn ich muss ja möglicherweise serverseitig eine Transaktion aufspannen. Die Persistenz-Odysee ist aber nocht nicht vorbei. Wenn die geänderte Objektliste und ggf. das Löschprotokoll wieder beim WCF-Dienst angekommen sind, muss die Objektliste zuerst wieder am ObjectContext attached werden. Dabei generiert der Kontext das Protokoll der Änderungen quasi nachträglich. Allerdings kann auch der ObjectContext die fehlenden RowState-Informationen nicht aus dem Ärmel schütteln. Er braucht dazu entweder eine Sicherheitskopie der ursprünglichen Objektliste oder er schaut in der Datenbank nach (will heißen, die Daten alle nochmal aus der Datenbank abrufen und vergleichen). Gelöschte erkennt er beim Attachen nur, wenn man eine Sicherheitskopie angibt. Ansonsten selbstgebasteltes Löschprotokoll mit Schleife durchgehen und für jeden DeleteObject aufrufen.

    Ich finde, da machen die "fetten" typisierten DataSets von ADO.NET eine ganz gute Figur neben den hochgelobten schlanken Objekten. Wenn ich zusätzliche DB-Roundtrips bzw. Netzwerklast für Sichungskopien der Objektlisten im Ursprungszustand mitzähle, ist an OR-Mapping nichts schlankes mehr zu erkennen. Nur wesentlich mehr Arbeit und auch noch weniger Komfort beim clientseitigen Databinding.

    Aber auch Typisierte DataSets sind nicht immer die Guten. Wenn es z.B. um Interoperabilität geht, fallen sie sofort durch. Ein Java-Client, der z.B. via SOAP auf einen WCF-Service zugreift, wird wenig Freude haben, wenn er ein DataSet deserialisieren soll. Leider enthält auch die XML-Serialisierung von DataSets .NET spezifische Inhalte. Auch Unabhängigkeit der DAL-Implementierung von einem bestimmten RDBMS ist mit normalem ADO.NET fast komplett Handarbeit (Und zwar wesentlich mehr, als ein bischen Detach- und Attach-Aufwand). Da macht die abstrakte Modellierung der DAL mit dem Entity Framework mehr Spaß. Es schreibt auch nicht jeder verteilte Anwendungen. Bei eine Standard-ASP.NET-Lösung ist es z.B. überhaupt nicht nötig Objektlisten zu detachen.

    Am Ende kommt es auf das konkrete Projekt und dessen Umgebung an, welche Technologie sinnvoller ist. 

  • Visual Studio 2008 macht TableAdapter für n-Tier-Anwendungen salonfähig

    Der Beitrag kommt zwar etwas spät, aber besser als nie. Wink

    Ich hatte mich vor einiger Zeit mal über TableAdapter ausgelassen (hier nochmal zum Nachlesen). Das Problem von TableAdaptern ist, dass sie scheinbar untrennbar mit dem DataSet verwurstelt sind. Datenstrukturen und die Datenzugriffslogik müssen bei einer n-Tier-Anwendung aber voneinander getrennt sein. Spätestens in verteilten Lösungen sind TableAdapter deshalb bis einschließlich Visual Studio 2005 nicht zu gebrauchen.

    Neben all den hochtrabenden neuen Datentechnologieen (LINQ, Entity Framework ...) die das (mittlerweile nicht mehr ganz) neue Visual Studio 2008 mitbringt, haben die Meisten ein kleines aber feines Feature übersehen. Im DataSet-Designer ist es nämlich seit Visual Studio 2008 möglich, die eigentliche DataSet-Definition in ein anderes Visual Studio-Projekt der selben Projekmappe auszulagern. Der Designer-Part und die TableAdapter verbleiben dabei im ursprünglichen Projekt. Es wird sozusagen nur die "Schnittstelle" ausgelagert. Dazu muss man das Projekt, welches die DataSet-Klassen aufnehmen soll einfach auswählen (Siehe folgender Screenshot; Klicken zum vergößern).

    n-Tier DataSet

    Die MSDN Library spricht von n-Tier-DataSets und n-Tier-Datenanwendungen. Ausführliche Infos und How-To´s gibts hier: http://msdn.microsoft.com/de-de/library/bb384587.aspx
    DataSet-Designer und TableAdapter sind seit Visual Studio 2008 nun auch für Leute interessant, die keine Spaghetti-Code-Anwendungen schreiben. Ab sofort sind deshalb auch TableAdapter cool YesCool.

    Es ist beruhigend, dass auch bestehende Technologieen ab und zu mal etwas Pflege erfahren, statt den Hypes zu huldigen!

  • Dienste einer n-Tier Anwendung in eine klare Hierarchie bringen

    Auf der guide to C# Live! Winter Edition hatten wir einige Diskussionen über die Architektur von Business
    Anwendungen (Ganz ähnlich übrigens auch auf mycsharp.de in folgendem Beitrag:
    http://www.mycsharp.de/wbb2/thread.php?threadid=61812). Den von mir vorgestellte Ansatz, die einzelnen
    Dienste in Kategorieen einzuteilen und diese in einer Hierarchie anzuordnen, war manchen nicht ganz
    verständlich gewesen. Der Bitte, das Ganze doch mal aufzuzeichnen, bin ich nun nachgekommen.
    Folgende Skizze kann hoffentlich Abhilfe schaffen und helfen, den Ansatz besser zu verstehen:

    Skizze hierarchischer Geschäftsdienste

    Eine Dienste haben gar keine Pfeilspitzen abbekommen. Das liegt daran, dass in der Skizze keine Clients
    und auch keine Stapelverarbeitungsdienste (z.B. Rechnungsdruck) enthalten sind.
     
     
    Man kann sehr schön sehen, wie viele Abhängigkeiten es zwangsläufig gibt. Die Hierarchie gibt vor, dass
    Dienste nur andere Dienste konsumieren dürfen, wenn diese über ihnen angebordnet sind. Niemals dürfen
    Dienste andere Dienste konsumieren, die darunter oder auf gleicher Ebene angeordnet sind.
    Diese Hierarchie muss allerdings vom Entwickler-Team auch so eingehalten werden. Es ist ein Konzept
    bzw. eine Konvention. In einem drei bis vier Mann Team habe ich sehr gute Erfahrungen mit diesem Modell
    gemacht. In größeren Teams ist da, denke ich, die Qualitätssicherungs-Abteilung gefordert. Damit alle auch
    nach der Selben Hierarchie entwickeln, sollte diese unbedingt Dokumentiert werden (z.B. wie oben).
     
    Ein Aspekt ist auf der Skizze allerings nicht abgebildet. Und zwar die Kommunikation nach außen. Wenn
    ein Dienst externe Dienste (also z.B. einer Fremd-Applikation) konsumieren soll, muss dies immer entkoppelt
    passieren. Das größe Problem dabei ist, Dinge wie Mandantenverwaltung, Sitzungen, Sicherheit und Locking
    mit der externen Anwendung auf einen Nenner zu bekommen. Portal-Adapter-Paarungen zwischen internem
    und externem Dienst können dabei für die Entkopplung und ggf. erforderliches Schnittstellen-Mapping sorgen.
    Ein generischer Weg wäre z.B. der BizTalk Server.
     
    Wenn man SOA ernsthaft umsetzen möchte, muss es sogar so sein, dass alle Dienste theoretisch
    austauschbar sind. Das würde bedeuten, dass jeder Dienst auch eigene Kontrakte für alles, was er konsumiert.
    Ohne Bus-System geht dann natürlich nichts mehr. Der Entwicklungs- und Testaufwand vervielfacht sich,
    wenn die komplette Kommunikation über ein Bus-System laufen soll.
     
    Aber auch ohne Bus-System bringt der Hierarchische-Ansatz eine Menge. Die Abhängigkeiten werden auf ein
    Mindestmaß reduziert und folgen klaren Regeln. Dienste lassen sich gut testen, da man für einen Test den
    Zugriff auf höher liegende Dienste auch auf einen Dummy-Dienst umleiten kann. Die Lösung ist in sich klar
    strukturiert und die Kommunikation zwischen den Diensten funktioniert über explizite Schnittstellen. Die
    Entwicklungsarbeit im Team lässt sich gut Aufteilen und parallele Entwicklung von Diensten ist - insofern
    man Contract-First durchzieht - auch kein Problem. Die Entwicklung solcher Dienste ist einfach und nicht an
    komplexe Container-Modelle oder Vererbungsbäume gebunden. Die Einarbeitungszweit für neue Entwickler ist
    minimal - vorausgesetzt die Infrastrukturdienste (oben gelb dargestellt) stehen schon und es wurde eine intuitive
    API für die Infrastruktur geschaffen (z.B. generischen Service-Locator, Microkernel, Statische Hilfsklasse für
    den Sicherheitsdienst und das Locking). 

  • guide to C# Live! Winter Edition 2008

    Logo guide to C Sharp Live

    Ich war da! Es war eine tolle Veranstaltung. Golo hat den Teilnehmern
    in den drei Tagen die Themen Software-Architektur, LINQ und WPF
    näher gebracht. Statt vieler Folien und langen Monologen, hat der
    Eisbär auf Dynamik am Flipchart und viel Interaktion mit den
    Teilnehmern gesetzt. Deshalb war die Veranstaltung alles andere
    als langweilig.

    Am zweiten Tag habe ich noch einen kleinen Beitrag zum Thema
    Windows Communication Foundation beigesteuert. Den Quellcode
    meiner zwei kleinen WCF-Demos (und der net.tcp-Versionen, die
    beim live Codieren leider nicht auf anhieb geklappt hatte
    ) gibts
    hier zum runterladen:

    http://yellow-rainbird.de/files/folders/quellcode/entry49.aspx

    Viel Spaß damit!

  • mycsharp.de Community Treffen

    Anlässlich des fünften Geburtstags von mycsharp.de findet am 30.08.2008 ein Community Treffen in Köln statt. Ich werde auf jeden Fall da sein und freue mich schon darauf, einige myCSharper leibhaftig kennen zu lernen.

    http://www.mycsharp.de/wbb2/thread.php?postid=329415#post329415

     

    Eingetragen Aug 27 2008, 08:04 von Rainbird mit no comments
    Abgelegt unter: ,
  • Fun: Klassische 2D-Spiele erstellen

     Bild1

    Wer schon immer mal klassische 2D-Rollenspiele in der Art von Zelda oder Final Fanatasy III machen wollte, ohne gleich ein C#-Megaprojekt zu starten, sollte sich mal den RPG Maker VX ansehen. Der RPG Maker ist ein Editor für 2D-Rollenspiele. Karten, Items und Monster lassen sich kinderleicht zuammenklicken. Wem das nicht reicht, kann mit Ruby Skripte schreiben oder auch die Game Engine direkt anpassen. Für alle Spielrelevanten Dinge wie z.B. Sprites bietet die API RGSS fertige Objekte an. Eine .NET Schnittstelle ist zwar nicht integriert, aber man kann Windows-API-Funktionen oder native C/C++ DLLs aufrufen.

    Herstellerseite des RPG Makers VX

    Eingetragen Apr 24 2008, 01:39 von Rainbird mit no comments
    Abgelegt unter: , , ,
  • Die neue erweiterte Version meines n-Tier Architekturbeispiels ist da!

    Endlich ist es soweit. Ich habe die Zeit gefunden, das Beispiel im ursprünglich geplanten Umfang fertigzustellen.
    Das Ergebnis gibts im Download-Bereich von yellow-rainbird.de und auf www.mycsharp.de kostenfrei zum runterladen.

    Jetzt herunterladen

    Als kleines Zusatzfeature kann man nun auch die Oberflächensprache zur Laufzeit ändern. Dies zeigt auch, wie einfach man mit dem .NET Framework Anwendungen lokalisieren kann.

    Screenshot

  • Lagermodul für Architekturbeispiel Rainbird.Examples.NTier fast fertig

    Das zweite Modul mit dem Namen Lageverwaltung für mein kleines n-Tier-Architekturbeispiel ist fast fertig und wird in Kürze hier und auf mycsharp.de veröffentlicht. Einen ersten Screenshot davon gibts hier: Screenshot

     

  • Ich möchte für Typisierte DataSets eine Lanze brechen

    Ich höre immer wieder Leute sagen, Typisierte DataSets seien böse. Im Jahre 2003 wollte ich davon auch noch nichts wissen. Aber Typisierte DataSets, wie sie Visual Studio 2005 erzeugt sind eine feine Sache. Ich habe mich deshalb gefragt, warum Typisierte DataSets so verteufelt werden?

    Höchstwahrscheinlich ist der DataSet-Designer von Visual Studio schuld. Wenn man als fauler Designer-Fan eine SQL Server Tabelle aus dem Server-Explorer per Drag&Drop in den DataSet-Designer zieht, passiert das hier:

    Screenshot

    Der Designer erstellt zwar automatisch eine schöne DataTable im DataSet, die alle Spalten der SQL Server Tabelle enthält, aber er hängt unten etwas dran (Fokus des bedrohlichen roten Wirbels im Bild). Es ist ein sogenannter TableAdapter. Zweck eines TableAdapters ist es, die DataTable, an der er hängt, mit Daten aus einer Datenbank zu füllen und Änderungen an der DataTable in einer Datenbank zu persistieren. Ein DataSet bzw. eine DataTable ist ein Container-Objekt, welches verwendet wird, um strukturierte Daten zwischen Komponenten auszutauschen. Man kann auch sagen ein DataSet ist eine Datenstruktur. So ein Container sollte passiv sein. Das heißt er sollte von "außen" befüllt werden und sich nicht selbts füllen. Der TableAdapter macht genau das Gegenteil. Er verwandelt das DataSet selbst in eine aktive Komponente. Und damit nicht genug. Ein Datenbankzugriff benötigt natürlich immer eine Verbindungszeichenfolge. Die hat der Designer heimlich, still und leise nebenbei als Anwendungseinstellung angelegt. So bekommt das Visual Studio-Projekt indem das DataSet liegt, plötzlich und automatisch eine Anwendungskonfigurationsdatei (App.config) untergeschoben:

    <?xml version="1.0" encoding="utf-8" ?>
    <
    configuration
    >
        <
    configSections
    >
        </configSections
    >
        <
    connectionStrings
    >
            <
    add name="WindowsApplication2.Properties.Settings.NTierExampleConnectionString"
                
    connectionString="Data Source=AMILO;Initial Catalog=NTierExample;Integrated Security=True"
                
    providerName="System.Data.SqlClient"
    />
        </
    connectionStrings
    >
    </
    configuration>

    Spätestens jetzt haben bestimmt viele auf das kleine X rechts oben geklickt und sich nach einem OR-Mapping Werkzeug umgesehen.

    Wenn der TableAdapter der Böse ist, liegt es klar auf Hand, was zu tun ist, um sinnvoll mit Typisierten DataSets arbeiten zu können. Idea Richtig, kein Drag&Drop aus dem Server-Explorer! Stattdessen Tabellen, Spalten, Schlüssel und Beziehungen manuell im DataSet-Designer zusammenklicken. Das ist etwas mehr Arbeit, aber man erhält hinterher ein sauberes DataSet, welches von keiner Datenquelle abhängig ist. Füllen und Persistieren des DataSets kann so eine eigenständige Geschäftskomponente übernehmen. Dem DataSet ist es egal, von welcher Datenbank die Daten kommen und wohin Änderungen persistiert werden.

    Screenshot

    Es gibt noch einen Grund, warum DataSets im allgemeinen verpöhnt sind. Scheinbar denken viele Leute, Typisierte DataSets müsse man immer als Ganzes einsetzen. Also in etwa so:

    // Neues Produkt Management-DataSet erzeugen
    ProductManagementDataSet dataContainer = new ProductManagementDataSet();

    Oft braucht man aber nur eine Tabelle und nicht drei auf eimal. Auch Beziehungen um zwischen Eltern- und Kind-Datensätzen zu springen, werden eher selten benötigt. Trotzdem arbeiten die meisten Tutorials, Bücher und Beispiele zu ADO.NET und DataSets immer mit ganzen DataSets. Dabei sind DataTables eigenständige Objekte, die auch dann alleine leben können, wenn sie in einem Typisierten DataSet definiert wurden. Wenn ich z.B. nur mit Produkten arbeiten will, mich aber Kategorieen und Preise gerade nicht interessieren, verwende ich auch nur die entsprechende DataTable und nicht das ganze DataSet:

    // Neue Produkt-Tabelleninstanz erzeugen
    ProductManagementDataSet.ProductsDataTable dataContainer = new ProductManagementDataSet.ProductsDataTable();

    Jetzt beginnt das Argument "DataSets haben zu viel Overhead und sind unhandlich!" zu bröckeln. Ich neige dazu für jeden Bereich einer Geschäftsanwendung ein Typisiertes DataSet zu erstellen, welches die Datenstrukturen für diesen Bereich enthält. Diese DataSets werden in separate Assemblies gelegt. So können verschiedene Komponenten und Prozesse mit den selben Datenstrukturen arbeiten. Alles ist typsicher und hat den vollen Komfort von DataSets/DataTables.

    Da Typisierte DataSets von System.Data.DataSet und deren Tabellen von System.Data.DataTable abgleitet sind, kann man mit Typisierten DataSet alles machen, was man mit den Basisklassen auch machen kann (z.B. DataView darauf anwenden, Filtern, Suchen, Zusammenführen, etc.). Was den Komfort angeht, sind DataSets/DataTables unschlagbar (Ich lasse mich natürlich gerne vom Gegenteil überzeugen)!

    Wer Typisierten DataSets trotzdem noch nicht über den Weg traut, dem möchte ich gerne folgendes Architekturbeispiel von mir ans Herz legen: .NET Applikationsserver auf mycsharp.de. In diesem kleinen Projekt werden DataSets als Datentransfer-Objekte eingesetzt, die strukturierte Daten zwischen einem kleinen Applikationsserver und einem Windows.Forms-Client übertragen.

    Fazit:

    Typisierte DataSets sind cool.Cool
    Typisierte DataTables sind cool.Cool
    TableAdapter sind böse Lightning und damit der eigentliche Teufel Devil, den man austreiben sollte.

  • Diagnosewerkzeug für VSTO Deployment-Probleme

    Ich bin heute ziemlich lange an einem Problem mit einem VSTO Word Add-In gesessen. Trotz korrket installierter VSTO 2005 SE Runtime und Primary Interop Assemblies für Office 2003 wollte das Word Add-In einfach nicht laufen. Ein anderes VSTO Add-In in Outlook hingegen lief ohne Probleme.

    Nach langer Suche in TechNet und MSDN habe ich irgendwann ein kleines Werkzeug mit dem schönen Namen Microsoft PSS VSTO 2005 Client TroubleShooter gefunden. Der TroubleShooter prüft, ob alle DLLs, die VSTO Add-Ins benötigen in der richtigen Version installiert sind und zeigt das Ganze in einer übersichtlichen Liste an. Zusätzlich werden noch bestimmte Einstellungen aufgeführt.

    Screenshot

    In meinem Fall hatte Word eine Datei mit dem Namen _msaccess.exe.config als Konifurationsdatei für das VSTO Add-In herangezogen. Das war eine ziemlich alte Konfigurationsdatei, die ich einmal für ein .NET 1.1 Assembly angelegt hatte, die via COM-Interop von Microsoft Access aufgerufen worden war. Die Konfiguration hatte damals die Verwendung von .NET Framework Version 1.1 erzwungen. Bei Access hatte der vorangestellte Unterstrich erfolgreich verhindert, dass die CLR diese Datei als Konfigurationsdatei verwendet. Dass Word diese Datei automatisch angezogen hat, verwundert mich sehr. Ich hätte es verstanden, wenn die Datei winword.exe.config geheißen hätte. 

    Der TroubleShooter hatte die alte Anwendungs-Konfigurationsdatei in seiner Liste aufgeführt und mich so auf die Fehlerursache aufmerksam gemacht. Nach dem löschen der _msaccess.exe.config  hatte das VSTO Word Add-In sofort funktioniert.

    Da VSTO Add-Ins nicht sagen, wenn ihnen irgendwas wehtut, sondern einfach garnichts machen, sollte man vor dem Ausrollen eines Add-Ins auf Produktiv-Maschinen den TroubleShooter zur Hand nehmen und überprüfen, ob die Konfiguration und die installierten Pakete in Ordnung sind. 

  • Rainbird´s Blog

    Es ist soweit! Ich gehe nun auch unter die Blogger.
    Mein Blog ist hauptsächlich dem Thema Softwareentwicklung mit dem .NET Framework gewidmet.

    Natürlich sieht jetzt alles noch etwas kahl aus, aber das wird sich bald ändern.
    Für die Zukunft wünsche ich viel Spaß beim lesen.

    Ich freue mich immer über Feedback zu meinem Blog oder zu yellow-rainbird.de allgemein.
    Fragen, Meinungen oder konstruktive Kritik bitte per E-Mail an hagen.siegel@the-rainbird.de senden.

    Rainbird

    Eingetragen Mrz 10 2008, 06:49 von Rainbird mit 1 comment(s)
    Abgelegt unter:
© Copyright 2008-2009 Yellow und Rainbird. Alle Rechte vorbehalten.
Powered by Community Server (Non-Commercial Edition)