12. April 2011, 18h, Wien: Der NServiceBus

Von Mario Meir-Huber Autor Feed 29. March 2011 20:16
Am 12. April 2011 ab 18 Uhr berichtet uns Christian Folie über seine Erfahrungen mit NServiceBus. Er hat sich auch um die Räumlichkeiten gekümmert.Das Treffen findet bei securityresearch.at, Favoritenstraße 16 – 2. Stock, 1040 Wien statt. Anfahrt: http://www.securityresearch.at/home/about/how-to-get-here/ Adresse: securityresearch.at Favoritenstraße 16 – 2. Stock 1040 Wien Wann? Dienstag, 12. April · 18:00 - 21:00 Weitere Infos auf Facebook: Eventseite: http://www.facebook.com/event.php?eid=203139199704297 .NET Open Space Wien: http://www.facebook.com/pages/NET-Open-Space-Austria/127092064018829

Event

Tags:  Feed Tag

ASP.NET MVC 3 Tutorial #1 – Das Model View Controller (MVC) Pattern erklärt

Von Mario Meir-Huber Autor Feed 21. March 2011 22:31
Nachdem auf CodeFest noch etwas wenig Content zu Asp.NET MVC 3 vorhanden ist, habe ich mich dazu entschlossen eine neue Tutorial-Reihe zu diesem Thema zu starten. Im ersten Post möchte ich darstellen, was das MVC Pattern eigentlich genau ist, bevor wir uns auf ASP.NET MVC tatsächlich stürzen. MVC steht nicht für “Mercedes Benz Veteranen Club” sondern für “Model-View-Controller”. Das MVC Pattern wurde erstmals 1978 durch Trygve Reenskaug beschrieben. Trygve arbeitete damals an Smalltalk. Da dieses Pattern bereits 33 Jahre  alt ist, gehört es definitiv zu den Urgesteinen der Software-Patterns. Heute findet man eine Vielzahl an MVC Frameworks für die unterschiedlichen Frameworks und Plattformen. Das MVC Pattern wird auch oft in etwas abgewandter Form verwendet, wie etwa dem MVP (Model View Presenter) und dem MVVM (Model View ViewModel) Patterns. Das MVC Pattern ist heutzutage eine Standardlektüre an jeder Universität und jeder Schule an der Softwareentwicklung gelehrt wird. Wie auch immer – mit ASP.NET MVC ist nun auch ein schlagkräftiges MVC Framework für .NET vorhanden. Prinzipiell bietet das MVC-Pattern eine relativ große Flexibilität, welche von der jeweiligen Implementierung abhängt. Doch wofür stehen nun die eigentlichen Begriffe? Model Das Model stellt die Daten dar, welche für die Anwendung verwendet werden. Je nach Anwendung kann das beispielsweise eine Person, ein Produkt oder viele andere Dinge sein. In manchen Implementierungen wird die Geschäftslogik in das Model ausgelagert. Hierbei teilen sich die Meinung ob dies nun richtig oder falsch sei. Idealerweise sollte keine Logik im Model sein. View Der View dient der Anzeige der Daten und stellt dem Benutzer gewisse Interaktionsmöglichkeiten zur Verfügung. Dies können Beispielsweise Dateneingaben oder Datenmanipulationen sein. Wichtig ist jedoch, das der View auf gar keinen Fall Geschäftslogik enthalten darf. Der View ist nur eine Anzeige, nicht jedoch die Verarbeitung dieser Daten. In Asp.NET MVC gibt es einige ViewEngines, wie etwa Razor. Controller Der Controller hat die Aufgabe, Views anzuzeigen und das Modell an den View zu übergeben. Der Controller verarbeitet Benutzereingaben und leitet diese an die dafür zuständigen Layer weiter. In Asp.NET können die Controller sehr komfortabel über die URL des Browsers aufgerufen werden. Wie dies funktioniert wird in einem späteren Artikel erklärt. Asp.NET MVC hat einige tolle Möglichkeiten, welche in den kommenden Wochen in weiteren Tutorials erklärt werden. Weitere Informationen: Trygve Reenskaug über MVC: http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf Josh Smith erklärt MVVM auf MSDN; http://msdn.microsoft.com/en-us/magazine/dd419663.aspx Martin Fowler über Model View Presenter: http://www.martinfowler.com/eaaDev/uiArchs.html#Model-view-presentermvp

Patterns und Practices für die Softwareentwicklung in .NET: die Enterprise Library. Teil 4: Unity und der Service Locator in Office Anwendungen (VSTO)

Von Mario Meir-Huber Autor Feed 2. February 2011 12:23
“Für viele Vorgänge, welche man tagtäglich in der .NET Entwicklung benötigt gibt es bereits viele hilfreiche Libraries. In dieser Serie werden best practices vom Patterns&Practices Team vorgestellt. Alle diese Beiträge können durch den Tag “p&p” abgerufen werden.” Eine kleine, wenn auch nicht weiter wesentliche Eigenheit für Unity und dem ServiceLocator ergibt sich in der Office Entwicklung. Hier verwendet man häufig den Ribbon als UI Element. will man Unity für irgendwelche Elemente im Ribbon verwenden, so kann es sein das Unity “noch nicht konfiguriert” ist. Der Grund ist das Ladeschema für Office. Hierzu möchte ich mal aufzeigen wie Office Solutions geladen werden: (Quelle: http://msdn.microsoft.com/en-us/library/bb386298.aspx) 1. Die Office Anwendung sucht nach Addins in der Registry 2. Wird ein Office-AddIn gefunden, so wird nacheinander das Deployment manifest und das Application manifest geladen. 3. Im Anschluss daran wird die Assembly an sich geladen und ist “Betriebsbereit”. Zwischen dem AddIn und der Office-Anwendung kommt es nun zu Aufrufen auf das Objektmodell und zu CallBacks und Events. Sieht man etwas tiefer rein in die Anwendung, so ergibt sich noch folgender Ladezyklus: Was bedeutet dies nun für Entwickler, die Unity in einem Office-AddIn verwenden? Nachdem der Ribbon vor dem eigentlichen AddIn (ThisAddIn_Startup") geladen wird, muss man dies natürlich in der Anwendungsentwicklung berücksichtigen. Hierfür muss der Container im Ribbon Startup initialisiert werden.

Patterns und Practices für die Softwareentwicklung in .NET: die Enterprise Library. Teil 3: Unity und der Service Locator in Silverlight

Von Mario Meir-Huber Autor Feed 24. January 2011 14:49
“Für viele Vorgänge, welche man tagtäglich in der .NET Entwicklung benötigt gibt es bereits viele hilfreiche Libraries. In dieser Serie werden best practices vom Patterns&Practices Team vorgestellt. Alle diese Beiträge können durch den Tag “p&p” abgerufen werden.” In den vorigen Beiträgen habe ich den Service Locator und Unity vorgestellt. Dies war rein auf “Standard” .NET Anwendungen bezogen. In Silverlight ist es nicht möglich, eine XML-basierte Konfiguration zu verwenden. Der Grund ist das Silverlight den Namespace System.Configuration derzeit (Version 4) nicht kennt. Daher muss man Konfigurationen per Quellcode regeln. Auf Codeplex gibt es einige Open-Source Projekte, welche dies auch lösen doch wollen wir uns hier Unity in der Reinform ansehen. Es wäre auch denkbar das man sich seinen eigenen Configuration-Reader schreibt. Doch der Aufwand dürfte wohl kaum in Relation zu den Output stehen. Eine Instanz wird über “RegisterInstance” registriert, welches auch im Unity für das .NET Framework funktioniert. Dies habe ich jedoch nicht vorgestellt da wir hier ohnehin XML für die Konfiguration verwendet haben. Microsoft.Practices.Unity.UnityContainer uic = new Microsoft.Practices.Unity.UnityContainer(); uic.RegisterInstance(typeof(IImportService), new ImportService()); uic.RegisterInstance(typeof(ILanguageService), new LanguageService()); uic.RegisterInstance(typeof(IPageService), new PageService()); uic.RegisterInstance(typeof(IEventService), new EventService()); UnityServiceLocator usl = new UnityServiceLocator(uic); ServiceLocator.SetLocatorProvider(() => usl); Somit ist Unity auch in Silverlight einfach verwendbar.

Patterns und Practices für die Softwareentwicklung in .NET: die Enterprise Library. Teil 2: Unity und der Service Locator

Von Mario Meir-Huber Autor Feed 23. November 2010 09:35
“Für viele Vorgänge, welche man tagtäglich in der .NET Entwicklung benötigt gibt es bereits viele hilfreiche Libraries. In dieser Serie werden best practices vom Patterns&Practices Team vorgestellt. Alle diese Beiträge können durch den Tag “p&p” abgerufen werden.” Wie bereits im ersten Post versprochen wird auf das vorher erstellte Beispiel ein Service Locator aufgesetzt. Hierfür wird ServiceLocation vom Pattern&Practices Team verwendet, welches Unity verwenden kann. Doch was genau macht ein ServiceLocator und wozu verwendet man diesen? Die durch Dependency Injection erreichte loskoppelung muss natürlich “irgendwie” adressierbar bleiben. Hierfür schaltet man oft einen Service Locator dazwischen, welcher es uns nun ermöglicht ein Service anhand eines gewissen Typen (Interfaces) ausfindig zu machen. Dieser Servicelocator fungiert als zentrale Registrierung für Services, welche die Anwendung verwendet. Ein wichtiger Vorteil des ServiceLocators ist es, dass Codeteile einfacher zum Testen sind. Man holt sich nur das Interface, nicht jedoch das konkrete Service – Unity kümmert sich um die richtige Auflösung. Services können, da zu jedem Service im Normallfall ein Interface existiert, einfach gemockt werden. Somit kann man eine Implementierung flexibel austauschen, ohne das die Anwendung selbst etwas davon mitbekommt – ein “new” fällt also weg. In der unten dargestellten Abbildung ist ein solcher Vorgang dargestellt. Hierbei wird der Zugriff auf einen Webdienst abstrahiert. die Anwendung (als Business Application bezeichnet) holt sich in diesem Fall den Webservicezugriff. Die Anwendung weis jedoch nicht über die Klasse “WebServiceImpl” bescheid. Dies könnte auch “WebServiceImplMock” sein. Der ServiceLocator liefert das eigentliche Interface zurück. Doch wie sieht dies jetzt im Quellcode aus? Nehmen wir mal an, wir wollen die Klasse “IApplicationPageService” aus unserem letzten Beispiel verwenden. Hierfür würde man NICHT so vorgehen: IApplicationPageService service = new ApplicationPageService(); Damit hätten wir wieder eine Abhängigkeit auf die konkrete Implementierung und diese müssten wir, sollte eine neue Implementierung, z.B. “FastApplicationPageService” eingebaut werden, überall austauschen. Dies macht keinen Sinn. Im Normalfall ist die konkrete Implementierung gar im Using – in der Anwendung muss ich mir darüber schlichtweg keine Gedanken machen. Mit einem Service Locator sieht es nun folgendermaßen aus: var pagesvc = ServiceLocator.Current.GetInstance<IApplicationPageService>(); Wie man hier sieht, es wird kein “new” verwendet. In unserem Fall würde Unity darüber entscheiden ob ein “new” im Hintergrund verwendet wird oder das Service als Singleton zurück geliefert wird. Wie dies unterschieden wird habe ich bereits im ersten Beitrag (Konfiguration) erklärt. Dies macht die Anwendung wesentlich flexibler als bisher. Was noch notwendig ist, bevor man den ServiceLocator verwenden kann ist dessen Assoziierung mit Unity sowie die Referenzierung der Library notwendig. ServiceLocation ist in “Microsoft.Practices.ServiceLocation” enthalten: Die Integration mit Unity erfolgt folgendermaßen: UnityServiceLocator loc = new UnityServiceLocator(myContainer); ServiceLocator.SetLocatorProvider(() => loc); Wer sich jetzt wundert wo “ServiceLocator” herkommt: ist statisch ;). Viel Spaß mit Service Location! Referenzen: Service Locator: http://martinfowler.com/articles/injection.html#UsingAServiceLocator

Patterns und Practices für die Softwareentwicklung in .NET: die Enterprise Library. Teil 1: Unity

Von Mario Meir-Huber Autor Feed 18. November 2010 12:00
“Für viele Vorgänge, welche man tagtäglich in der .NET Entwicklung benötigt gibt es bereits viele hilfreiche Libraries. In dieser Serie werden best practices vom Patterns&Practices Team vorgestellt. Alle diese Beiträge können durch den Tag “p&p” abgerufen werden.” Unity ist eine der Bestandteile der Enterprise Library, welche Patterns und Practices für die .NET Entwicklung beinhaltet. Unity verwendet man, um Dependency Injection zu ermöglichen. Dependency Injection ist eine Implementierung des IoC Patterns (Inversion of Control – zu deutsch in etwa “Umkehr der Kontrolle). Das bedeutet das die Erzeugung und das Verknüpfen von Objekten ausgelagert wird. Der Vorteil hierbei ist die verbesserte Testbarkeit, jedoch entsteht auch der Nachteil das die Projekte eventuell unüberschaubar werden. Unity regelt nun die eben beschriebene Verwaltung. Oft wird Unity auch ohne andere Komponenten der Enterprise Library eingesetzt, da Dependency Injection eine zentrale Komponente in der Softwareentwicklung ist. Unity verwendet man dann, wenn man viele Abhängigkeiten zwischen Objekte hat, die Objekte sehr komplex sind und man daher abstraktion benötigt, wenn man Abhängigkeiten zur Laufzeit ändern will oder dergleichen. Was braucht man um mit Unity loszulegen? Als erstes benötigt man die Enterprise Library. Zum Zeitpunkt der Erstellung dieses Beitrages war die Version 5.0 aktuell. Diese kann man über http://unity.codeplex.com/ erhalten. Danach muss man Unity nur noch in das Projekt einfügen. Dann kann man an sich bereits mit der Erstellung von Unity Containern beginnen. Diese Container kann man entweder per Code erstellen oder über die App.config (Client Anwendungen) oder der Web.config (Webanwendungen). In diesem Beitrag wollen wir die Dependencies nur per XML konfigurieren. Hierfür muss, sollte die Konfiguration nicht vorhanden sein, eine neue Anwendungskonfiguration eingefügt werden. Nun kann man mit der XML-Konfiguration beginnen. Wir fügen die Inhalte in den Knoten “configuration” ein. Hier müssen wir zum Einem Unity konfigurieren (configSections) und zum anderen Unity selbst im Knoten “unity”. Der Unterknoten “typeAliases” von “unity” enthält hierbei die Interfaces und Implementierungen die verwendet werden. Ferner wird ein Container benötigt, welche die Auflösung der Services erstellt. Der Container wird in der Sektion “containers” definiert. Ein Typ wird mit dem Typen und der jeweiligen Implementierung (mapTo) aufgelöst. Services, die man hier verwendet müssen unter “typeAliases” angegeben werden. Will man ein Service als Singleton registrieren so kann man dies im Knoten “lifetime” erledigen. Ein komplettes Beispiel ist in der folgende XML Datei dargestellt. <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> </configSections> <unity> <typeAliases> <!-- Interfaces --> <typeAlias alias="ILanguageService" type="Some.Application.ILanguageService, Some.Services"/> <typeAlias alias="IApplicationPageService" type="Some.Application.IApplicationPageService, Some.Services"/> <typeAlias alias="IApplicationSettingsService" type="Some.Application.IApplicationSettingsService, Some.Services"/> <!-- Implementations --> <typeAlias alias="LanguageService" type="Some.Application.LanguageService, Some.Services"/> <typeAlias alias="ApplicationPageService" type="Some.Application.ApplicationPageService, Some.Services"/> <typeAlias alias="ApplicationSettingsService" type="Some.Application.ApplicationSettingsService, Some.Services"/> </typeAliases> <containers> <container name="basicServices"> <types> <type type="ILanguageService" mapTo="LanguageService"> <lifetime type="singleton" /> </type> <type type="IApplicationPageService" mapTo="ApplicationPageService"> </type> <type type="IApplicationSettingsService" mapTo="ApplicationSettingsService"> </type> </types> </container> </containers> </unity> </configuration> Schlussendlich muss Unity auch in der Anwendung noch konfiguriert werden. Hierfür erstellt man sich den UnityContainer und ließt die Konfiguration mit dem ConfigurationManager aus. Dies sieht dann folgendermaßen aus: UnityContainer myContainer = new UnityContainer(); UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity"); section.Configure(myContainer, "basicServices"); Im nächsten Teil werde ich den ServiceLocator einbauen, damit Unity interessanter zu verwenden ist.

Parallel Programming mit Microsoft .NET – kostenloses E-book

Von Petra Kleiber Autor Feed 27. September 2010 11:57
    Learn design patterns for decomposition and coordination on multicore architectures. Includes samples in C#, VB and F#!    Zum Download       Release Notes This is the final release to accompany Parallel Programming with Microsoft® .NET. It includes: Separate downloads of the sample code for every chapter in C#, Visual Basic and F#. Some fixes for minor bugs in the source code from Drop 7. An additional PDF containing answers to the end of chapter questions. System Requirements You will need .NET 4 and at least Visual Studio 2010 Professional to run the samples. However, you will need Visual Studio 2010 Ultimate to use some the parallel diagnostic tools such as the Concurrency Visualizer. Note: Visual Studio Express users will see the following message when you open the Visual Studio solution (.sln) file for each of these samples: "Solution Folders are not supported in this version of Visual Studio. Solution Folder 'Solution Items' will be displayed as unavailable." Although this folder is not available in Visual Studio Express, you can still build and run the projects. A separate "Book Samples - Express" solution is also provided. Refer to the README.txt file for a brief description of each project and which chapter it relates to.

Tags:  Feed Tag,  Feed Tag

18.10.-22.10.2010, Redmond, Symposium patterns & practices, Redmond

Von Petra Kleiber Autor Feed 3. August 2010 12:14
    The Microsoft patterns & practices Symposium is the event for software developers and architects to have engaging and meaningful discussions with the people creating the technologies and guidance aimed at addressing their scenarios. This 5-day event provides an environment to learn about and discuss a broad range of Microsoft development technologies and the opportunity to drill into the details with p&p and product team members and industry experts. Symposium Highlights · Keynote Sessions by Senior Microsoft Executives and Technical Industry Leaders including Jason Zander, Yousef Khalidi, and Charlie Kindel · 3 Developer Workshops on Enterprise Library, Prism and Windows Azure · 25 Thought-provoking sessions on Windows Phone 7, SharePoint, ASP.NET, Dependency Injection, Agile practices, and much more including patterns for how to apply these technologies in proven ways · Evening Networking Reception with entertainment, food and drinks · Symposium Party on Thursday Night at Lucky Strike Billiards in Bellevue · “Ask The Expert” Lunches and several Open Space sessions         Learn more about the Symposium on the web at patterns & practices Symposium @pnpsymposium #pnpsym Facebook      

Material & Downloads – 1st Microsoft Architect Conference

Von Mario Szpuszta Autor Feed 8. July 2010 15:01
It was a great pleasure for us and for me in specific hosting the 1st conference for software architects in the history of Microsoft Austria. Finally I managed getting all the material we are allowed to share from our speakers. A good time for a reflect a little bit on the conference. First of all the most important part: you can download all the presentations from the conference from the following Windows Live Skydrive folder: Click me to get to the folder As announced during the conference we were not allowed publishing all presentations. You definitely will find all presentations we were allowed to share at this place. The whole conference was really a great experience for us and for me. Therefore I want to especially say thank you to all participants of the conference – you made it a special event for us all and with that the you made this day and evening to a great memory. Some facts on the great day: 140 architects attended the event – sold out. Average session rating – 2,16 on a 1-9 scale (1=best) The top 3 sessions where: Architecture in Agile Projects – Mitch Lacey Cloud Computing – A Crash Course for Architects – Beat Schwegler Scalable, Evolveable, Understandable Event-based Components – Ralf Westphal A wine tasting until 23.00 with exciting wines from Johannes Fiala and superb discussions across the evening. As announced at the conference, it was the closing of a step and opening of a new step in my life. After a long and enjoying path with my career within the Developer and Platform Evangelism Group and my responsibility as an architect evangelist has ended with that conference. My next step has started a month ago as a senior architect within Microsoft enterprise services working for a really large, international customer. Thank you for a great time! Thank you for shaping the architect community together with me! Looking forward to meet you at one of the next architect forums either as participant or as invited speaker, maybe;) Cheers Mario

Design Patterns Teil 4: Datenzugriff/ Persistenz

Von Andreas Aschauer Autor Feed 2. March 2010 12:03
Seit dem letzten Teil der Design Patterns, oder besser gesagt “Best Practives” Reihe ist schon einige Zeit vergangen. Im vorangegangen Artikel haben wir kurz einen Ausflug ins ASP.NET MVC Framework gemacht. Nun ist es an der Zeit an Persistenz und Datenzugriff zu denken, die folgenden 2 Artikel werden dieses Gebiet abdecken. Wer Visual Studio verwendet kann natürlich die komplette “Infrastruktur” zum Datenzugriff mit Drag&Drop, zB. mittels LINQ to SQL Designer erzugen lassen. Wie es dann allerdings mit Testbarkeit und Wartbarkeit aussieht, muss nicht extra erwähnt werden. Wir wollen hier einen architektonisch sauberen Lösungsansatz verfolgen. Unser Beispiel soll in folgende Layer partitioniert sein, welche zugleich den Projektmappen unserer Solution entsprechen. Business Layer Die “dummen” Entitäten Service Layer Services setzten etwaige Businesslogik um Repositories Erledigen Persistenzaufgaben Anhand eines einfachen Beispiels gehen wir von “oben” (UI) bis nach ganz “unten” (Persistenz). Als Framework kommt Castle ActiveRecord zum Einsatz, da es mit minimalem Konfigurationsaufwand verwendbar ist und die Vorgehensweise zur Entwicklung einer Persistenzschicht richtig umsetzt. Das heisst: Die Datenbank wird aus den Businessobjekten erzeugt und nicht umgekehrt. Wir wollen Kunden und ihre Bestellungen darstellen und dazu noch ein bisschen Geschäftslogik, damit unsere Services etwas zu tun haben. Wir werden den Aufbau unserer Lösung ganz einfach beginnen und dann später noch architektonisch verfeinern, also Refactoring betreiben. Als erstes erstellen wir uns 2 neue Businessobjekte “Customer” und “Order”. Diese Businessobjekte sollten idealerweise nur dumme Datencontainer sein und keine Logik etc. enthalten. Die Klasse “Order” sieht dann vorläufig so aus: 1: public class Order 2: { 3: public Guid ID { get; set; } 4: public DateTime Date { get; set; } 5: public decimal OrderValue { get; set; } 6: public Customer Customer { get; set; } 7: } 8:  Den kompletten Sourcecode gibts unter “Downloads” als Archiv zum herunterladen, damit der Artikel nicht zu lange wird. So weit, so gut; Um nun eine Entität vom Typ “Order” persistierbar zu machen, müssen wir ActiveRecord und unser Businessobjekt noch passend konfigurieren. ActiveRecord setzt auf dem bekannten NHibernate Framework auf und wird einfach über Attribute im Code verwendet. Die fertige Order Klasse sieht folgendermassen aus: 1: [ActiveRecord] 2: public class Order : ActiveRecordBase<Order> 3: { 4: [PrimaryKey] 5: public Guid ID { get; set; } 6: [Property] 7: public DateTime Date { get; set; } 8: [Property] 9: public decimal OrderValue { get; set; } 10: [Property] 11: public Customer Customer { get; set; } 12:  13: } Für die Klasse Customer gehen wir gleich vor. Interessant ist noch die 1:n Beziehung Customer –> Order. Diese wird mit dem Attribut [BelongsTo] auf der einen Seite und [HasMany] auf der Gegenseite abgebildet. Also in der Klasse Order ist die Eigenschaft Customer mit [BelongsTo] markiert und in der Klasse Customers ist die Eigenschaft Orders mit [HasMany] markiert. (siehe Source). Folgendes Klassendiagramm ergibt sich nun, für das wir ein Schema erzeugen werden um die Daten zu persistieren.   Um das zu erreichen muss ActiveRecord noch für die entsprechende Datenquelle die erzeugt werden soll konfiguriert werden. Die Konfiguration geschieht mittels XML. Entweder als eigenen xml Datei oder als Sektion in der app.config. Unsere Konfiguration sieht folgendermassen aus (Für SQL Server 2005) 1: <?xml version="1.0" encoding="utf-8" ?> 2: <activerecord> 3: <config> 4: <add 5: key="connection.driver_class" 6: value="NHibernate.Driver.SqlClientDriver" /> 7: <add 8: key="dialect" 9: value="NHibernate.Dialect.MsSql2005Dialect" /> 10: <add 11: key="connection.provider" 12: value="NHibernate.Connection.DriverConnectionProvider" /> 13: <add 14: key="connection.connection_string" 15: value="Data Source=.;Initial Catalog=PersistencyTest;Integrated Security=SSPI" /> 16: </config> 17: </activerecord> Die Initialisierung geht ganz einfach: 1: public static void Initialize() 2: { 3: IConfigurationSource config = new XmlConfigurationSource("ar.config"); 4: var asm = Assembly.Load("PersistencySample.Business"); 5: ActiveRecordStarter.Initialize(asm, config); 6: } Unsere komplette Assembly PersistencySample.Business wird nach, mit [ActiveRecord] markierten Klassen durchsuch (Achtung: Diese Variante kann bei vielen Klassen in der Assembly sehr langsam sein!) –> Für erweiterte und andere Varianten der Initialisierung siehe den AR Configuration Guide (unter Links). Das Ganze wird NATÜRLICH getestet…siehe Design Patterns Artikel – Teil 3 ! Diesmal mit MSTest: Ein neues Testprojekt hinzufügen und einfach mit Rechtsklick auf die entsprechende Methode einen Unit Test erzeugen lassen 1: [TestMethod()] 2: public void InitializeTest() 3: { 4: Application.Initialize(); 5: Assert.IsTrue(true); //Wenn kein Fehler auftritt->success 6: } Das Erzeugen des Schemas selbst ist ein Einzeiler: 1: public static void CreateSchema() 2: { 3: ActiveRecordStarter.CreateSchema(); 4: } Und MSTest gibt uns das grüne Licht !   Natürlich ist im Sinne von Test-Driven-Development die Verwendung eines Datenbanksystem nicht optimal. Eine Lösung hierfür ist die verwendung einer In-Memory Datenbank wie SQLite (ActiveRecord unterstützt diese). Im nächsten Teil werden wir die Repositories implementieren und etwas Refactoring betreiben. Downloads Castle Active Record Links AR Configuration and Initialization

Design Patterns: Teil 3 - Testbarkeit

Von Andreas Aschauer Autor Feed 11. January 2010 11:51
Ziel dieser Blogreihe soll es nicht sein Pattern A bis Z vorzustellen (dafür gibt es genügend Bücher) sondern praktische Tutorials zu liefern, wie man Design Patterns und Entwicklungsmethodiken einsetzen kann um sich das Entwicklerleben zu erleichtern und die Qualität des Codes zu verbessern. In den vorangegangen Artikeln der Design Patterns Reihe haben wir schrittweise eine modulare und lose gekoppelte Architektur entwickelt. Am Beispiel des LogWriters war schön zu erkennen, wie einfach und schnell man Modularisierung und lose Kopplung auch in scheinbar kleinen Anwendungen (die ja meist dann zu unternehmenskritischer Software heranwachsen) erreichen kann. Jetzt gehen wir einen Schritt weiter und überlegen wozu man das ganze verwenden kann. Eine gute Architektur sollte im Entwicklungsprozess auch so gut als möglich “ausgenutzt” werden, denn die Architektur allein schafft noch keinen hochqualitativen Entwicklungsprozess. Der erste Schritt dazu sind Entwicklertests! Damit ist nicht Debugging gemeint sondern eine Testgetriebene-Entwicklung, die die Brücke zwischen funktionierendem Code und Code, der funktioniert UND der Spezifikation entspricht, schlägt. Test-Driven-Development (TDD), das MVC Framework für ASP.NET und die hier vorgestellten Tools werden noch genauer in Folgeartikeln behandelt, vorerst wollen wir anhand eines kurzen Beispiels mittels ASP.NET MVC ansehen, wie leicht man Unit-Tests in einer gut strukturierten Anwendung unterbringen kann. Bis dahin sei auf die Links unten verwiesen. Erstellt man in Visual Studio ein neues MVC Projekt aus der Vorlage “ASP.NET MVC 2 Web Application”, welche via Download des ASP.NET MVC Frameworks mitgeliefert wird, wird man anfangs sofort gefragt, ob man seiner neuen Solution gleich Unit Tests hinzufügen möchte – wollen wir natürlich! Im Anhang ist der Source Code einer Minianwendung zu finden, die nichts anderes tut als eine Eingabemaske zur Verfügung zu stellen um einen Kunden neu anzulegen. Was wollen wir erreichen? Wir wollen nun testen ob beim Anlegen eines Kundendatensatzes die Muss-Felder geprüft werden und entsprechende Fehlermeldungen erscheinen. Was wir nicht wollen, ist das bei jedem Testdurchlauf Daten in die Datenbank geschrieben werden – 1. dauert das lange wenn viele Tests laufen und 2. müsste bei komplexeren Szenarien jedesmal die Datenbank zurückgesetzt werden. Genau hier kommt unsere Architektur wie wir sie im letzten Artikel erarbeitet haben zum Einsatz. Dazu implementieren wir den CustomerController folgendermassen: 1: private readonly ICustomerRepository _customerRepository; 2:  3: public CustomerController(ICustomerRepository customerRepository) 4: { 5: _customerRepository = customerRepository; 6: } 7:  8: public ActionResult Create(Customer customer) 9: { 10: if(string.IsNullOrEmpty(customer.FirstName)) 11: { 12: ModelState.AddModelError("FirstName","Firstname must not be empty!"); 13: } 14: _customerRepository.Save(customer); 15: return View(); 16: } Wichtig ist hierbei nur die Tatsache, dass die Abhängigkeit des Controllers vom CustomeRepository, dass das eigentlich Speichern übernimmt injeziiert wird. Das ermöglicht uns dass wir ein “gefaktes” CustomerRepository implementieren, also eine Klasse “CustomerRepositoryMock” die einfach ICustomerRepository implementiert und die Methode Save() so defniert wie wir sie zu Testzwecken wollen. Nämlich entweder komplett ohne Funktion oder es könnte auch eine In-Memory Datenbank wie SQLite verwendet werden. Die Implementierung ist im anghängten Sourcecode ersichtlich um den Artikel kurz zu halten. Im Prinzip folgen ICustomerRepository, CustomerRepository und CustomerRepositoryMock dem gleichen Prinzip wie die LogWriter im vorigen Artikel. Das Schöne ist nun, dass die Methode Create() des CustomerControllers einfach getestet werden kann und GANZ WICHTIG (!!) sie muss NICHT geändert werden um produktiv zu funktionieren! Es muss nur die injeziierte Instanz von ICustomerRepository zB via Windsor Container umgestellt werden -> siehe Design Patterns Teil 2 Der Test sieht dann so aus: 1: [TestMethod] 2: public void ValidationMessagesShouldAppearOnCreate() 3: { 4: var custController = new CustomerController( 5: new CustomerRepositoryMock()); 6:  7: var customer = new Customer() 8: {FirstName = ""}; 9:  10: custController.Create(customer); 11:  12: Assert.AreEqual(1, custController.ModelState.Count); 13: Assert.AreEqual("Firstname must not be empty!", custController.ModelState["FirstName"].Errors[0].ErrorMessage); 14:  15: } Die 2 Assert() Anweisungen prüfen, ob im ModelState der Key “FirstName” vorhanden ist und ob der Eintrag die richtige Fehlermeldung enthält. Hier ist auch schön zu sehen, wie einfach die UI im ASP.NET MVC Framework getestet werden kann. Eine Einführung ins MVC Framework und noch viel mehr zu TDD und Unit Testing folgen in den nächsten Artikeln! Links/Downloads: Beispiel Source Code ASP.NET MVC Framework Einführung in TDD

Design Patterns: Teil 2 – Dependency Injection mit Castle Windsor

Von Andreas Aschauer Autor Feed 2. December 2009 13:30
In Teil 1 der Reihe haben wir die Ideen hinter den Prinzipien “Inversion-of-Control” und “Dependency Injection” kennen gelernt. Die Anwendung dieser Techniken trägt sehr viel zu einer modularen und leicht wartbaren und erweiterbaren Software-Architektur bei. Im 2. Teil beschäftigen wir uns mit der zentralen Komponente (Container), die Instanzen erzeugt und alle Abhängigkeiten automatisch zur Laufzeit erkannt und erfüllt. Zur Erinnerung hier nochmals die Abbildung aus dem ersten Artikel. Viele Frameworks existieren, die die Funktionalität dieser “Container” Komponente umsetzen. In diesem Artikel werde ich denCastle Windsor Containerverwenden. Um das LogManager Beispiel sinvoll zu erweitern, wollen wir eine GUI (hier WinForms) hinzufügen. Jedes Form soll protokolieren wenn es geladen wurde. Anstatt das in jedem konkreten Form zu machen, erzeugen wir eine Basisklasse von der unsere Forms im Endeffekt ableiten –> KISS & DRY !!. Hier führen wir einen neuen Konstruktor für ein, der als Parameter eine Instanz von LogManager übergibt. 1: public class BaseForm : Form 2: { 3: private readonly LogManager _logManager; 4:  5: public BaseForm() {} 6:  7: public BaseForm(LogManager logManager) 8: { 9: _logManager = logManager; 10: } 11:  12: protected override void OnLoad(EventArgs e) 13: { 14: base.OnLoad(e); 15: _logManager.WriteToLog(string.Format("Form {0} loaded", Name)); 16: } 17: } Wir haben jetzt zusätzlich zu der Abhängigkeit LogManager –> ILogWriter noch die Abhängigkeit BaseForm –> LogManager. Würden wir ohne Hilfe eines IoC Containers (Windsor Container) arbeiten, müssten wir zuerst händisch eine Instanz einer ILogWriter Implementierung erzeugen, danach einen LogManager und dann könnten wir eine Instanz von BaseForm erzeugen. Hierbei würde wieder jede Flexibiltät verloren gehen, da wir zur Entwicklungszeit im Code angeben müssten, welche konkreten Implementierungen verwendet werden. Deshalb lassen wir die Arbeit den Castle Windsor Container erledigen…zur Laufzeit! Schritt 1: Download des Frameworks (Microkernel/Windsor ist das was wir aus der Liste brauchen) Schritt 2: Referenzieren der Assemblies In der Projektmappe mit Rechtsklick “Add Reference” folgende Assemblies referenzieren. Schritt 3: Konfiguration des Containers, registrieren der Komponenten Alle Klassen müssen zuerst in unserem Container als Komponenten registriert werden, damit Instanzen und Abhängigkeiten erzeugt bzw. aufgelöst werden können. Im einfachsten Fall geschiet das direkt im Code. Hier habe ich eine ApplicationServives Klasse als Singleton implementiert (Statische Klasse), die beim Start der Anwendung einmal die Methode InitializeContainer aufruft. 1: public static class Application 2: { 3: private static IWindsorContainer _container; 4:  5: static void InitializeContainer() 6: { 7: _container = new WindsorContainer(); 8:  9: _container.AddComponent("LogManager", typeof(LogManager)); 10: _container.AddComponent("ILogWriter", typeof(ILogWriter), typeof(FileLogWriter)); 11: _container.AddComponent("BasePage", typeof(BasePage)); 12: } 13: } 14:  15: public static T GetComponent<T>() 16: { 17: return (T)_container.Resolve(typeof(T)); 18: } Die Methode registriert die benötigten Komponenten im Container. Interessant ist dabei Zeile 10, in der ILogWriter registriert wird. Genau hier wird umgesetzt worüber im 1. Teil geschrieben wurde. Es wird das Interface ILogWriter registriert und im 3. Paramater wird EINE KONKRETE Implementierung von ILogWriter angegeben, die verwendet werden soll. Man muss sich die Interfaces als Services vorstellen, die gewisse Operationen anbeiten (zB WriteToLog) und die konkreten Klassen als Komponenten welche diese Services umsetzen. Wird das Service ILogWriter angefordert (siehe nächstes Code Snippet), wie im Konstruktor von LogManager der Fall ist, instanziiert der Container die Klasse FileLogWriter. 1: ILogWriter logWriter = ApplicationServices.GetComponent<ILogWriter>(); Wird das Ganze so wie hier im Code gemacht, gewinnt man noch nicht viel Flexibiltät. Was man gewinnt ist ein zentraler Ort an dem man die Komponenten verwalten kann! Denkbar ist zum Beispiel die Inititalize Methode in einer eigenen Assembly zu definieren und pro System (Test / Produktion/ ..) eine Initialisierungs-Assembly zu verwenden. Es reicht, für die Initialize Methode der Test- Assembly, eine Zeile zu tauschen und man arbeitet mit dem Service ILogWriter gegen eine Mock-Implementierung. 1: .. 2: _container.AddComponent("ILogWriter", typeof(ILogWriter), typeof(MockLogWriter)); 3: .. Noch flexibler ist es XML Konfigurationsdateien zu verwenden. Dabei hat man die Wahl zwischen einer “eigenständigen” XML-Datei oder man fügt der app.config (oder web.config) eine entsprechende Sektion hinzu. In unserem Fall sähe die app.config folgendermassen aus: 1: <?xml version="1.0" encoding="utf-8" ?> 2: <configuration> 3: <configSections> 4: <section 5: name="castle" 6: type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" /> 7: </configSections> 8: <castle> 9: <components> 10: <component 11: id="LogManager" 12: type="ContainerDemo.LogManager, ContainerDemo" /> 13: <component 14: id="ILogWriter" 15: service="ContainerDemo.ILogWriter, ContainerDemo" 16: type="ContainerDemo.FileLogWriter, ContainerDemo" /> 17: <component 18: id="BasePage" 19: service="ContainerDemo.BasePage, ContainerDemo" /> 20: </components> 21: </castle> 22: </configuration> Die Initialiserung ist analog zu oben, jedoch muss beim Erzeugen der Container Instanz noch ein Interpreter für XML mitgegeben werde, der Castle anweist in der Sektion “castle” der app.config die Konfiguration zu suchen. 1: _container = new WindsorContainer(new XmlInterpreter(new ConfigResource("castle"))); Soweit zu einem kurzen Überblick über Dependency Injection und Inversion-of-Control mit dem Castle Windsor Container. Die Möglichkeiten gehen weit über das hinaus was hier möglich ist zu zeigen. Viele Beispiele und die Dokumentation zu Castle Windsor finden sich in den Links unten. Links Castle Windsor Dokumentation Weitere Frameworks Spring.NET Liste von IoC Frameworks von Scott Hanselmann

Design Patterns: Teil 1 – Inversion of Control & Dependency Injection

Von Andreas Aschauer Autor Feed 27. November 2009 11:24
Bevor wir uns nach und nach den eigentlichen Design Patterns widmen, beginnen wir mit der Vorstellung zweier Entwicklungspraktiken, die die Qualität, Testbarkeit, Skalierbarkeit und Wartbarkeit von Software dramatisch erhöhen können. Beachtet man, auch bei “Mini” Entwicklungen, diese Entwicklungspraktiken, spart man sich als Entwickler, sehr viele Nachbesserungs- und Anpassungsarbeiten. Die Idee hinter Dependency Injection und allgemein Inversion-of-Control, ist die Anwendung des sogenannten “Hollywood Prinzips” –> “Don’t call us, we call you!” Was bedeutet das für die Software Entwicklung? In einem klassischen Ansatz werden Klassen und deren Abhängigkeiten hard-codiert. Das heisst es wird mit konkreten Klassen gearbeitet, welche über Konstruktoren oder Properties Abhängigkeiten erhalten. Somit wird schon zur Kompilierzeit für jedes konkrete Objekt festegelegt, welche Interaktionen mit anderen Objekten bestehen. Einfach gesagt, werden alle Objekte fix miteinander “verdrahtet”. Änderungen sind nicht mehr möglich (ausser durch Umbauarbeiten im Sourcecode), ein dynamisches Beeinflussen von Interaktionen ist gar nicht möglich. Abb.1 – LogManager ist direkt abhängig von einer konkreten Implementierung von LogWriter  Besser ist eine genaue Umkehrung dieser Vorgehensweise. Also eine Komponente (Container in Abb.2), die Objekte erzeugt und selbst zur Laufzeit entscheidet, wie die einzelnen Abhängigkeiten “befriedigt” werden und welche konkreten Implementierungen zu verwenden sind, übernimmt die Kontrolle; daher –> Inversion-of-Control. Die Verwendung diese Prinzips führt implizit schon zu besserer Software, da man mit Abstraktionen wie Interfaces und Abstrakten Klassen arbeiten muss um dieses dynamische Verhalten zu erreichen.   Abb.2 – Der Container erzeugt Instanzen und Injiziert Abhängigkeiten Angenommen es soll ein einfacher Logger erstellt werden, der Zeichenketten in ein Log File schreibt. Ad-hoc könnte man mit der folgenden einfachen Methode diese Aufgabe lösen. 1: public class LogManager 2: { 3: public void WriteToLog() 4: { 5: var logWriter = new LogWriter(); 6: logWriter.WriteToLog("Hello World!"); 7: } 8: } 9:  10: public class LogWriter 11: { 12: public void WriteToLog(string message) 13: { 14: File.AppendAllText(@"C:\sample.log", message); 15: } 16: } Diese Implementierung setzt zwar die Anforderung um, aber was passiert wenn sich die Anforderungen ändern, oder neue Anforderungen hinzukommen? Angenommen es soll nun nicht mehr in eine Datei geschrieben werden, sondern in eine Datenbank oder eine beliebige andere Quelle. Was wenn im Entwicklungssystem die Datenbank in die geloggt werden soll gar nicht verfügbar ist, wie kann man das ganze testen?! Mit der vorliegenden Lösung sehr schwierig bis gar nicht. Es wird zwar anfängliche Anforderung umgesetzt, jedoch ist der Code weder einfach wartbar noch skalierbar und testbar. Drehen wir den Spiess um: Lassen wir den Aufrufer, die Abhängigkeiten “zusammenbasteln”. Der selbe Logger könnte mittels einfacher Dependency Injection (hier: Constructor Injection) so aussehen: 1: public class LogManager 2: { 3: private ILogWriter _logWriter; 4:  5: public LogManager(ILogWriter logWriter) 6: { 7: _logWriter = logWriter; 8: } 9:  10: public void WriteToLog(string message) 11: { 12: _logWriter.WriteToLog(message); 13: } 14:  15: } Die konkrete Implementierung von LogWriter wurde durch ein Interface ersetzt und die Abhängigkeit des LogManagers von der einer konkreten Implementierung wurde entfernt. Die jeweilige Instanz wird einfach über den Konstruktor zur Laufzeit (!) “injiziert”. Welche Vorteile bring das: Testbarkeit: Um den LogManager zu testen reicht eine Dummy (Mock) – Implementierung von ILogWriter aus. Mehr zu Mocking Wartbarkeit: Ändern sich die Anforderungen können neue LogWriter (Implementierungen von ILogWriter) hinzugefügt/ausgetauscht werden. Separation of Concerns – Eines der Wichtigsten Prinzipien im Software Engineering viele, viele mehr… Dieses, sehr einfache Beispiel, verdeutlicht, wie einfach man Dependency Injection umsetzen kann und, welche Vorteile sich sofort daraus ergeben. Damit haben wir natürlich erst ein bisschen an der Oberfläche gekratzt. In Teil 2 der Artikelreihe werden wir sehen wie man mit Hilfe eines Frameworks (Castle Project), dynamisch zur Laufzeit entscheiden kann welche Implementierungen von Komponenten verwendet werden. Der Castle Microkernel übernimmt dabei die Rolle des Containers in Abb.2. Das Framework nimmt einem dabei die ganze Arbeit zur korrekten Instanziierung der Objekte und der Injizierung der Abhängigkeiten ab. Im Beispiel oben, würde das Framework erkennen, dass zur Erzeugung einer Instanz von LogManager eine Implementierung von ILogWriter erforderlich ist. Welche Implementierung das sein wird, wird aus einer Konfigurationsdatei gelesen. So kann zum Beispiel zum Testen und Entwickeln eine Dummy-Implementierung von ILogWriter eingesetzt werden. Durch eine einfache Änderung in einer Konfigurationsdatei wird die Komponente die ILogWriter implementiert auf die “echte” Implementierung geändert – ohne eine Veränderung am Quellcode ! Damit ist es möglich Anwendungen zu erstellen, die aus Komponenten zusammengesetzt sind und ohne Codeänderungen an verschiedene Umgebungen angepasst werden könnnen, rein durch die passende Konfiguration. (zB. unterschiedliche Back-End Systeme, Datenbanken, Web-Services,…) Links: Für Interessierte, die sich nach diesem Artikel für Software Engineering begeistern können: Software Design Prinzipien: SOLID, DRY, YAGNI Theorie: Theoretische Einführung in Dependency Injection und Inversion of Control 

Design Patterns: Start der Pattern Reihe

Von Andreas Aschauer Autor Feed 23. November 2009 10:27
Die Microsoft Web-Entwicklungsplattformen machen es durch ihre zu Grunde liegende Architektur - Trennung von Layout-Logik – einfacher, gut strukturierte Web Anwendungen zu entwickeln. “Sauberer” Code geht meist mit einem höheren Initialaufwand beim Umstieg auf die entsprechende Technologie einher. Was dabei oft vergessen wird, sind die Zeiten und Aufwände, die investiert werden müssen, wenn Anwendungen mit “Spaghetti-Code”, also schnell zusammengewürfelte Systeme und Module in die Produktion kommen. Die Testphase und Validierung ob überhaupt den Spezifikationen entsprochen wurde bei der Entwicklung, sind meist unnötig lange und aufwendig und belasten bis zu einer Abnahme durch den Auftraggeber das Entwicklungsteam sehr. Weiters sind die Kosten zur Behebung eines Fehlers, der NACH der Entwicklungsphase gefunden wird um ein vielfaches höher und jede Änderung in einer schlecht strukturierten Software ist sehr aufwändig. Kurzum: Lieber ein höherer Initialaufwand als eine langwierige, teure und strapaziöse Produktivstellung und eine schwere Wartbarkeit. Die Lösung: Software Design Patterns Sobald Mario von der PDC zurück ist, wollen wir hier eine Blogreihe starten, die sich mit Design Patterns und ihrer Anwendung in Web Applikationen beschäftigt. Im Vordergrund soll dabei nicht die Theorie stehen, sondern WIE ich ein Pattern einsetzen kann um meine Anwendungen modularer zu machen und WAS genau die Vorteile sind. Den Start der Reihe machen wir mit einer Einführung in Dependency Injection / Inversion of Control . Eine Technik die es ermöglicht lose gekoppelte Module zu entwickeln, die leicht ausgetauscht werden können. Falls jetzt noch bei einigen Lesern Verwirrung herrscht: Mit ein paar Praxisbeispielen (Code) werden wir versuchen, das Thema klar und verständlich zu machen.

Entwickler Wettbewerbe:

Wettbewerbe

Entwickler Events:

Developer Events

App für Windows 8, Windows Phone oder/und Azure? Diese Events zeigen Dir, wie es geht:

Mehr Information

Aktuelle Downloads

Visual Studio Downloads
 
Windows Azure Free Trial
Instagram
CodeFest.at on Facebook

Datenschutz & Cookies · Nutzungsbedingungen · Impressum · Markenzeichen
© 2013 Microsoft. Alle Rechte vorbehalten · BlogEngine.NET 2.7.0.0 · Diese Website wird für Microsoft von atwork gehostet.
powered by atwork