Archiv der Kategorie: Development

Die großen 4: Pfadfinderregel, Wirtschaftlichkeit, Clean Code, SOLID Principles

Was ist damit gemeint? Gemäß der Pfadfinderregel soll ein Entwickler Code immer besser hinterlassen, als er ihn vorgefunden hat. Clean Code oder guter Code ist häufig dann erreicht, wenn das Mindestmaß an essentiellen Code Prinzipien umgesetzt ist. Das sind die sogenannten SOLID Principles. Jedoch ist guter Code kein Selbstzweck, sondern dient dem größeren Ziel der Wirtschaftlichkeit.

Im folgenden Video zeige ich an einem Praxisbeispiel, wie ich bei einem bestehendem, eher unwichtigem Projekt vorgegangen bin. Timeboxed in 1h so viel refaktorisieren und den Code verbessern wie möglich. Dabei gehe ich auf Prinzipien wie DRY und OCP ein und zeige Techniken wie DI, sowie Tools wie den IoC Container Castle Windsor.

Feedback nehme ich wie immer gerne mit. Wenn ihr mehr von solchen Videos sehen wollt, schreibt mir das in die Kommentare, damit ich weiß: Hier lohnt es sich mehr zu machen.

Zum YouTube Video

Durch Klicken auf das Bild geht es zum Video

Advertisements

Build Server endlich ohne DevExpress

DevExpress ist leider alles andere als vorbildlich, was den Einsatz auf Build Servern angeht. Weder bietet das Unternehmen NuGet Packages, noch lässt sich die Lizenzprüfung auf dem Build Server deaktivieren.

Mit einem kleinen Trick lässt sich aber die Installation umgehen. Hierzu ruft ihr den Installer auf dem Build Server/Agent auf, loggt euch mit euren Daten an dem unten aufgeführten Screenshot ein und brecht nach erfolgreichem Login ab einfach ab.

DevExpress Login Dialog

Damit wurden mehrere Registry Einträge geschrieben, die leider maschinenspezifisch sind. Diese findet ihr hier:

  • HKLM\SOFTWARE\Classes\Licenses378852D-D597-4A32-B6D9-680A16A3CDA6\***
  • HKLM\SOFTWARE\Classes\Licenses\6F0F8269-1516-44C6-BD30-0E90BE27871C\***

Wenn ihr in den Projekten dann DLL-Referenzen aus einem Repository-Verzeichnis verwendet oder euch eigene NuGet Packages baut, benötigt ihr in Zukunft keine Installation mehr. Das gilt auch für Developer, die nicht an der UI mitentwickeln.

Wohin mit den Queries, Repositories und UnitOfWorks in meinen Anwendungsschichten

Am vergangenen .NET Open Space gab es eine Session namens „Repositories oder ORM“. Den Titel fand ich ein wenig unglücklich gewählt. Nutzt man nämlich einen OR-Mapper, so verwendet man implizit Repositories. Zumindest ist das beim Entity Framework der Fall. Dort entspricht der DbContext nämlich der UnitOfWork und die darauf implementierte generische Set-Methode liefert die Repositories zu allen Datenbank-Entitäten.

Grob gesagt sollte pro Geschäftsvorfall (aus Sicht der UI) ein DbContext erzeugt, darauf alle Änderungen und Abfragen ausgeführt und im Anschluss per Commit in einer Transaktion ausgeführt werden. Die Transaktion findet implizit statt, sodass ihr sicher sein könnte, dass entweder alles in die Datenbank geschrieben wurde oder nichts.

Nun wurde die Frage gestellt wie mit Abfragen zu Verfahren ist: Sollte man in allen Layern auf die Repositories zugreifen und dann per LINQ beliebig filtern? Ich bin der Meinung, dass man dies tunlichst unterlassen sollte. Stattdessen nutze ich in der Regel eine der zwei Möglichkeiten (welche sich beide gut zum Testen eigenen):

  • Eine dedizierte Repository-Implementierung, die intern die Abfragen kapselt. Das könnte zum Beispiel die Klasse ‚Rechnungen‘ mit der Methode ‚AlleMitDatumGrößerAls(DateTime datum)‘  sein. Idealerweise mappt das Repository ‚Rechnungen‘ dabei die Entitäten auf Business Objekte. AutoMapper kann in dem Fall viel Schreibarbeit abnehmen.
  • Sollten mehrere Repositories die gleiche Abfrage verwenden, so bietet es sich an die Query in eine eigene Klasse dafür zu extrahieren. Zum Beispiel die Klasse ‚FindeBenutzerMitId‘, welche im Konstruktor die Id übergeben bekommt. Auf der UnitOfWork lässt sich dann die Query z.B. in der Form ausführen: ‚uow.ExecuteQuery(new FindeBenutzerMitId(1))‘. Dafür muss allerdings erst die UnitOfWork um einen solchen Mechanismus erweitert werden. Ich hatte diesen Ansatz vor ein paar Jahren in diesem Video beschrieben.

Leider ist ein Blog Beitrag ungeeignet um ein solch komplexes Thema in der notwendigen Tiefe zu besprechen. Ziel war es daher nur Denkanstöße zu geben und eine Diskussion zu starten. Wer nützliche Ressourcen zu dem Thema hat oder wer andere Ansätze verfolgt, kann diese gerne in die Kommentare schreiben.

Paket vs. NuGet

Am vergangenen .NET Open Space haben einige Teilnehmer nach Erfahrungen zu Paket, der mehr oder weniger neuen Alternative zu NuGet. Mein Statement möchte ich an dieser Stelle für alle festhalten:

Wir haben unser ERP-System mit ca. 70 Projekten vor über 6 Monaten umgestellt und sind sehr zufrieden damit. Warnen muss ich lediglich vor 3 Punkten, die einem bewusst sein müssen:

  • Paket ist nicht in Visual Studio integriert und muss daher über die Kommandozeile ausgeführt werden. Eine Integration ist auch nicht geplant. (Aktualisiert: Ein entsprechendes GitHub Projekt steht zur Verfügung)
  • Jedes NuGet Package, welches die install.ps1 aufruft, funktioniert ggf. nicht richtig nach der Installation mit Paket. Das ist z.B. bei PostSharp der Fall, was ich hier beschrieben habe. Der geneigte Leser möge bitte bei PostSharp für das offene Issue dazu voten.
  • NET Core Projekte erlauben keine Assembly Referenzen mehr, sodass Paket nicht verwendet werden kann.

Die Gründe für einen Abgang von NuGet sind vielfältig und wurden vom Entwicklerteam selbst beschrieben. Mit annähernd allen Problemen räumt Paket auf. Um nur zwei davon zu nennen:

  • Mit dem Updaten von packages werden die Projektdateien nicht mehr verändert. Stattdessen werden lediglich 2 Dateien von Paket selbst aktualisiert. Damit gehören Merge-Konflikte der Vergangenheit an.
  • Einen Abhängigkeitsgraphen bekommt man ebenfalls mitgeliefert. Daraus lässt sich schnell schließen welches Package ein anderes in welcher Version referenziert.

Eine Frage beim Open Space war, ob sich damit auch das gleiche Package in unterschiedlichen Versionen einbinden lässt. Nein, das ist nicht der Fall, was aber nichts mit NuGet oder Paket zu tun hat. Das ist der Tatsache geschuldet, dass ein .NET Prozess eine Assembly nur in genau einer Version laden kann. Zum Lösen dieses Problems bedarf es also immer Binding Redirects. In NuGet 3 soll zumindest ein Feature zum einfachen Konsolidieren unterschiedlicher Versionen eingebaut sein.

Mit NuGet 3 soll ohnehin ein großes Redesign stattfinden, sodass ein näherer Blick darauf ratsam ist. Im Team Blog finden sich einige nützliche Ressourcen.

Ich wollte den Blog Post kurz halten, deshalb habe ich nicht alle Vorteile aufgezählt. Wenn aber ein Leser der Meinung ist, dass noch etwas unbedingt genannt werden soll, dann einfach in die Kommentare posten.

Nachgefragt – Interview mit Daniel Marbach zu MSpec

In einem Online Interview habe ich Daniel Marbach zur Zukunft des Open Source BDD Frameworks MSpec befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden nicht vorab abgesprochen, um ein authentisches statt ein werbelastiges Gesprächs zu führen.

 

image

Auf das Bild klicken um zum Video zu gelangen

 

An dieser Stelle möchte ich noch die Community aufrufen sich an der Weiterentwicklung zu beteiligen. Open Source Projekte leben von freiwilligen Helfern und Daniel macht da eine sehr gute Arbeit und ein tolles Produkt!

Fragen

  • Machine.Specifications
  • Was ist eigentlich ein BDD Framework
  • Stärken
  • Schwächen
  • Roadmap
  • Wie steht es um die Zukunftssicherheit
  • Tipps und Tricks
  • Ergänzende Frameworks
  • Gute Tests

 

Show Notes

How to get the PostSharp package running with Paket

Recently, I reported some difficulties that I‘ve experienced with the PostSharp NuGet package when I was using the new package manager Paket. I tracked the problem down to the ‚install.ps1‘ script which is executed by NuGet after adding PostSharp to a project. This PowerShell script (located under packages\PostSharp\tools) patches your project file. Since this behaviour is already proclaimed from the pulpit by NuGet, I hope that PostSharp is going to remove that asap. Until then, you can execute the script manually or patch the csproj-File by yourself.

In order to do that, insert the following 2 snippets at the the position shown in the screenshots:

   1: <DontImportPostSharp>True</DontImportPostSharp>

 

image

 

Don’t forget to change the relative path to your PostSharp package in the following snippet:

   1: <Import Project="..\..\packages\PostSharp\tools\PostSharp.targets" Condition="Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" /> 

   2: <Target Name="EnsurePostSharpImported" BeforeTargets="BeforeBuild" Condition="'$(PostSharp30Imported)' == ''">

   3: <Error Condition="!Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://www.postsharp.net/links/nuget-restore." />

   4: <Error Condition="Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://www.postsharp.net/links/nuget-restore." />

 

image

 

I also recommend you to activate the following PostSharp Option in Visual Studio:

image

Interview mit Daniel Marbach mitgestalten

Am 18. März wird mir Daniel Marbach ein Video Interview zu dem BDD-Framework Machine.Specifications geben. Ein kleiner Vorgeschmack gefällig?

Wodurch hebt sich MSpec von anderen BDD-Frameworks ab?

oder

Welche Features sind gerade in der Pipeline?

oder

Welche anderen Frameworks ergänzen MSpec gut?

Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die Richtung des Gesprächs mitgestalten, indem ihr mir rechtzeitig eure Fragen in die Kommentare postet.

%d Bloggern gefällt das: