Microservices don’t like thinking in conventional entities

I recently had one of these special AHA-moments in a workshop held by Udi Dahan, CEO of Particular. In his example he was using the classic entity of a customer.

To realise microservices means cutting functionality in a clean way and to transfer it into separate pillars (or silos). Each silo has to have the responsibility over it’s own data, on which it builds the respective business processes. So far, so good. But how can we realise this for our typical customer, who’s model is shown in the screenshot? Different properties are needed or changed by different microservices.

If the same entity is used in all pillars, there needs to be a respective synchronisation between all microservices. This results in a considerable impact on scalability and performance. In an application with lots of parallel changes of an entitiy the failing of the business processes will increase – or lead to inconsistencies in the worst case.

conventional entity of a customer

Udi suggests the following modelling

Customer is modelled with independent entities

To identify which data belongs together, Udi suggests an interesting approach:

Ask the operating department if changing a property has a consequence for another property.

Would changing the last name of customer have an influence on the price calculation? Or on the way of marketing?

Now we need to solve the problem of aggregation, for example if I want to show different data from different microservices in my view. In a classic approach we would have a table with following columns:

ID_Customer

ID_MasterData

ID_Marketing

ID_Pricing

This leads to the following two problems:

1. The table needs to be extended if a new microservice is added
2. If a microservice covers the same functionality in the form of data, you would have to add multiple columns for each microservice and allow NULL values as well

An example for the second point could be a microservice which covers the matter of payment methods. In the beginning you could only use credit cards and debit charges. Then Paypal. Bitcoin soon after. The microservice would have different tables on which the respective data for the payment method would be stored. In the aggregated table shown above it would be necessary to fill a separate column for each payment method the customer is using. If he doesn’t use it, a NULL value would be written. As you can see: This sucks.

Another approach is much more convenient for this. Which one this is and how it’s realised technically you can find on the GitHub repository of Particular.

 

Werbung

Microservices mögen kein Denken in klassischen Entitäten

Einen ganz besonderen AHA Moment hatte ich kürzlich in einem Workshop bei Udi Dahan, CEO von Particular. In seinem Beispiel ging es um die klassische Entität eines Kunden.

Microservices zu realisieren bedeutet Fachlichkeiten sauber schneiden und in eigenständige Silos (oder Säulen) packen zu müssen. Jedes Silo muss dabei die Hohheit über die eigenen Daten besitzen, auf denen es die zugehörigen Geschäftsprozesse abbildet. Soweit so gut. Doch wie lässt sich dies im Falle eines Kunden bewerkstelligen, der klassischerweise wie im Screenshot zu sehen modelliert ist? Unterschiedliche Eigenschaften werden von unterschiedlichen Microservices benötigt bzw. verändert.

Wird die gleiche Entität in allen Silos verwendet, muss es eine entsprechende Synchronisierung zw. den Microservices geben. Das hat erhelbiche Auswirkungen auf Skalierbarkeit und Performance. In einer Applikation mit häufig parallelen Änderungen an einer Entität wird das Fehlschlagen von Geschäftsprozessen zunehmen – oder im schlimmsten Fall zu Inkonsistenzen führen.

Klassische Kundeentität

 

Udi schlägt die folgende Modellierung vor:

Der Kunde wird durch unabhängige Entitäten modelliert

Zur Identifikation, welche Daten zusammengehören, schlägt Udi einen Interessanten Ansatz vor:

Fragt die Fachabteilung, ob das Ändern einer Eigenschaft Auswirkung auf eine andere Eigenschaft hat. 

Würde das Ändern des Nachnamens einen Einfluss auf die Preiskalkulation haben? Oder auf die Art der Marketings?

Nun gilt es noch das Problem der Aggregation zu lösen, sprich wenn ich in meiner Anzeige unterschiedliche Daten unterschiedlicher Microserivces anzeigen möchte. Klassischerweise würde es jetzt eine Tabelle geben, die die Spalten

 

ID_Kunde

ID_Kundenstamm

ID_Bestandskundenmarketing

ID_Preiskalkulation

 

besitzt. Das führt aber zu 2 Problemen:

1. Die Tabelle muss immer erweitert werden, wenn ein neuer Microservices hinzugefügt wird.
2. Sofern ein Microservices die gleiche Funktionalität in Form unterschiedlicher Daten abdeckt, müssten pro Microservices mehrere Spalten hinzugefügt und NULL Werte zugelassen werden.

Ein Beispiel für Punkt 2 wäre ein Microservices, der das Thema Bezahlmethoden abdeckt. Anfangs gab es beispielsweise nur Kreditkarte und Kontoeinzug. Dann folgte Paypal. Und kurze Zeit später dann Bitcoin. Der Microservices hätte hierzu mehrere Tabellen, wo er die individuelle Daten für die jeweilige Bezahlmethode halten würde. In oben gezeigter Aggregationstabelle müsste aber für jede Bezahlmethode, die der Kunde nutzt, eine Spalte gefüllt werden. Wenn er sie nicht benutzt, würde NULL geschrieben werden. Man merkt schon: Das stinkt.

Ein anderer Ansatz ist da deutlich besser geeignet. Welcher das ist und wie man diesen technischen realisieren kann, könnt ihr im GitHub Repository von Particular nachschauen.

 

Quellen zu Defensives Design und Separation of Concerns sind jetzt online

Den Quellcode zu meinen Vorträgen auf den Karlsruher Entwicklertagen und der DWX sind jetzt online:

• Zu Super Mario Kata mit Fokus auf Defensivem Design geht es hier.
• Zur Prüfsummen Kata mit fokus auf Separation of Concerns gelangt ihr hier.

Auf beiden Seiten findet ihr auch die Links zu den PowerPoint Folien. Im Juli 2018 werde ich den Code der Prüfsummen Kata noch in Form von Iterationen veröffentlichen und beide Talks als YouTube Video freigeben.

Defensives Design Talk auf der DWX

Ihr wollt Teile davon in euren Vorträgen verwenden, ihr wollt ein Training zu dem Thema oder ich soll dazu in euerer Community einen Vortrag halten, dann kontaktiert mich über die auf GitHub genannten Kanäle.

Workshop: Conquer your Codebase – Bewährter Clean Code aus der Praxis (Materialien)

Einen herzlichen Dank an alle Teilnehmer des Workshops am vergangenen Freitag beim Developer Open Space 2017. Trotz des völlig unterschiedlichen Backgrounds – von Ruby, über PHP, zu Java oder gar nicht objektorientierte Sprachen wie JavaScript – war ebenso alles vertreten wie vom Azubi bis hin zum Entwickler mit 20-jähriger Berufserfahrung.

Einer von vielen mutigen Freiwilligen

Den Code zur Super Mario Kata gibt es hier. Beachtet die neuen Anforderungen (9-12), die ich auf dem Heimweg im Zug noch hinzugefügt habe. Damit einhergehend habe ich noch ein Refactoring des Konzepts ‚Leben‘ durchgeführt, sodass keine Actions bzw. Funcs mehr an die Methoden übergeben werden müssen. Gleichfalls fällt das Branching-Statement raus und es ergibt sich eine nahezu völlig flexible Möglichkeit zur Erstellung von Spielmodi. Die Tests sind nun ebenfalls alle umgesetzt, was wir gegen Ende hin aufgrund von Zeitmangel ausgelassen haben. Eine Testmethode hat in der Regel eine Zeile und wie schon im Workshop erwähnt: Was gut zu testen ist, ist in der Regel auch eine saubere Lösung.

20 Teilnehmer mit unterschiedlichen Backgrounds

Derjenige, der noch eine Lösung mit dem Command-Pattern umsetzt und dadurch das Anpassen bestehender Klassen völlständig vermeidet, erhält von mir einen Gutschein für unsere Trainings. Damit kann er kostenlos an jedem beliebigen 3-tägigen Workshop in unseren Karlsruher Büros teilnehmen (Fahrt- und Übernachtungskosten sind ausgeschlossen).

Alle, die über den Workshop bloggen oder twittern, erhalten darüber hinaus noch einen 30% Rabattcode. Einfach Link schicken, dann kriegt er diesen per Mail.

Ein Teilnehmer versucht sich in einer Lösung mit Java statt C#

Weiterführende Links

• Das erwähnte Video zu Enumeration mit Verhalten könnt ihr hier anschauen.
• Danke an Tim für den Link zum Case Converter für Visual Studio.
• Außerdem lege ich euch die Reactive Extensions ans Herz, die es für unterschiedliche, gängige Programmiersprachen gibt.
• Git Snippet
• Wer noch ein wenig üben möchte, kann dies mit der erweiterten FizzBuzz Kata tun.
• Blog Post über die Migration von NHibernate zu EntityFramework in 3 Tagen.

 

Demnächst geht ein Video mit dem theoretischen Teil (Why-How-What) online, in dem ich nochmal die Zusammenhänge zw. „schlechtem Code“ und den Gründen dafür erläutere. Wer automatisch informiert werden will, wenn es veröffentlich wird, abonniert einfach meinen Blog oder schickt mir eine Nachricht.

 

 

Workshop: Conquer your Codebase – Bewährter Clean Code aus der Praxis

Am Developer Open Space 2017 halt ich einen 1-tägigen Workshop zu obigem Thema. In reduzierter, kompakter Form werde ich dazu bewährte Inhalte aus meinem 3-tägigen Seminar nehmen und die Ursachen für folgende Probleme adressieren:

• Unverständlicher bzw. schlecht wartbarer Code
• Bugs
• Skalierungsprobleme
• Go Live Probleme
• Verpasste Deadlines und lange Entwicklungszeiten

 

Wir werden uns anschauen wie es dazu kommen kann, z.B. weil

• die Infrastruktur nicht wiederverwendbar ist,
• die Domänenlogik nicht erweiterbar ist,
• eine falsche Nutzung der API möglich ist,
• der Code nicht ausdrucksstark ist,
• oder starke Abhängigkeiten bestehen.

 

Wir werden das Open Closed Principle genauer besprechen und Seperation of Concerns am konkreten Beispiel umsetzen. Speziell für Freunde der Objektorientierung werde ich je nach verfügbare Zeit praktische Lösungen zur Vermeidung von If-Else-Zweigen und NULL-Checks zeigen.

 

Ein Laptop mit Visual Studio oder Visual Studio Code und .NET 4.6 wären wünschenswert. Prinzipiell ist der Workshop aber für alle Entwickler des objektorientierten Paradigmas geeignet, da bis auf Delegaten (Action/ Func) und Erweiterungsmethoden kaum Sprachspezifika verwendet werden. Darüber hinaus können Teilnehmer auch ohne Hardware beiwohnen, weil wir beim Live Coding am Präsentations-PC mit Code Monkey Runden arbeiten werden.

Gerne dürfen die Teilnehmer mir vorab Fragen und Probleme z.B. hier in Form von Kommentaren oder per E-Mail zukommen lassen.

Open Closed Principle mit 2 Zeilen Code

In meinem Video zu 60 Minuten mit der Pfadfinderregel war ich noch die Lösung zu Castle.Windsor schuldig. In diesem Webcast zeige ich wie die CollectionResolver-Funktionalität genutzt werden kann, um nachträglich hinzugefügte Implementierungen automatisch im Container zu registrieren.

Dadurch kann das OCP vollständig eingehalten werden, da lediglich eine neue Klasse hinzugefügt werden und der restliche Code nicht angefasst werden muss. Den Code habe ich hier zur Verfügung gestellt. Fragen und Feedback einfach in die Kommentare.

	public class Installer : IWindsorInstaller
	{
	/// <summary>
	/// Performs the installation in the <see cref="T:Castle.Windsor.IWindsorContainer" />.
	/// </summary>
	/// <param name="container">The container.</param>
	/// <param name="store">The configuration store.</param>
	public void Install(IWindsorContainer container, IConfigurationStore store)
	{
	container.Kernel.Resolver.AddSubResolver(new Castle.MicroKernel.Resolvers.SpecializedResolvers.CollectionResolver(container.Kernel));
	container.Register(Components().ToArray());
	}
	private static IEnumerable<IRegistration> Components()
	{
	//have a look at https://github.com/castleproject/Windsor/blob/master/docs/registering-components-by-conventions.md
	yield return Classes //non abstract classes; you could also use Types.* for more choices
	.FromThisAssembly() //should be clear
	.IncludeNonPublicTypes() //since my implementations are internal, only the interface is public
	.BasedOn<IFoo>() //every class that implements this interface
	.WithService.Base() //also possible: .WithServiceFromInterface()
	.LifestyleTransient();
	yield return Component
	.For<IBar>()
	.ImplementedBy<Bar>()
	.LifestyleTransient();
	}
	}

view raw CastleWindsor.CollectionResolver.cs hosted with ❤ by GitHub

Durch Klicken auf das Bild geht es zum Video

Testen von Datenbankabfragen – Es geht auch einfach

In diesem Screencast zeige ich wie selbst Abfragen mit mehreren Bedingungen und Sortierungen einfach getestet werden können. Unter der Haube kommt das Entity Framework zum Einsatz. Davon kriegt man dank Dependency Injection aber nichts mit.

Die erwähnte Webcast Serie, sowie weiteren Beispielcode und das Projekt auf Github gibt es hier. Feedback oder Fragen nehme ich gerne entgegen. Wenn ihr wollt, dass ich die Serie fortsetze, sprecht mich über einen Kanal eurer Wahl an.

Bessere Enumerations in NET

Ist euch der Smell von typischen Enumerations auch schon in die Nase gestiegen? In diesem Webcast zeige ich eine Alternative zu den typischen Enums in NET. Damit können das Open Closed Principle und Separation of Concerns besser umgesetzt werden, was meiner Meinung nach zu einer höheren Kohäsion führt.

 

Weiterführende Links:

• Blogbeitrag von Jimmy Bogard (Hier gibt es den Code der EnumerationBase)
• Video von Jimmy Bogard (Das Enum Beispiel kommt bei 44.45min)
• Strategy Pattern mit IoC

 

Wie haltet ihr es mit Enums? Arbeitet ihr schon auf diese Weise? Wollt ihr mehr Webcasts zu Clean Code?

Flexibles Bootstrapping durch Composition

In diesem Webcast zeige ich unseren Kompositions-Ansatz für das Bootstrapping. Die Interfaces sind schmal, die Implementierungen überschaubar, das Ganze ist flexibel und lässt sich gut testen.

Hier der gezeigte Code:

   1: public class BootstrapperContext

   2: {

   3:     public BootstrapperContext()

   4:     {

   5:         AppConfig = new ApplicationConfig();

   6:         Container = new WindsorContainer();

   7:     }

   8:  

   9:     public IWindsorContainer Container { get; private set; }

  10:     public ApplicationConfig AppConfig { get; private set; }

  11: }

   1: public interface IAmABootstrapperAction

   2: {

   3:     void Execute(BootstrapperContext context);

   4: }

 

   1: public interface IAmABootstrapperComposition

   2: {

   3:     IEnumerable<IAmABootstrapperAction> Actions { get; }

   4: }

 

   1: public class BootstrapperExecutor

   2: {

   3:     public static void StartupApplication(IAmABootstrapperComposition bootstrapperComposition)

   4:     {

   5:         var exceptionMessage = "Beim Starten der Anwendung ist ein Fehler aufgetreten. Bitte den Support kontaktieren.\n\n";

   6:  

   7:         if (bootstrapperComposition.Actions == null || !bootstrapperComposition.Actions.Any())

   8:         {

   9:             throw new BootstrapperException(exceptionMessage, new ArgumentOutOfRangeException("Auf dem Bootstrapper waren keine Actions definiert"));

  10:         }

  11:  

  12:         var context = new BootstrapperContext();

  13:  

  14:         var time = TimedAction.Run(() =>

  15:                                    {

  16:                                        foreach (var action in bootstrapperComposition.Actions)

  17:                                        {

  18:                                            var actionName = action.GetType().Name;

  19:                                            SiAuto.Main.LogMessage(string.Format("{0} gestartet", actionName));

  20:  

  21:                                            var timeTaken = TimedAction.Run(() => { ExecuteAction(action, context, exceptionMessage); });

  22:  

  23:                                            SiAuto.Main.LogMessage(string.Format("{0} in {1} erfolgreich durchgeführt",

  24:                                                                                 actionName,

  25:                                                                                 timeTaken.Format())

  26:                                                );

  27:                                        }

  28:                                    });

  29:     }

  30:  

  31:     private static void ExecuteAction(IAmABootstrapperAction action, BootstrapperContext context, string exceptionMessage)

  32:     {

  33:         try

  34:         {

  35:             action.Execute(context);

  36:         }

  37:         catch (Exception ex)

  38:         {

  39:             SiAuto.Main.LogException(string.Format("Fehler beim Bootstrapping: {0}", ex.GetFullExceptionMessage()), ex);

  40:             throw new BootstrapperException(string.Format("{0}{1}", exceptionMessage, ex.GetFullExceptionMessage()), ex);

  41:         }

  42:     }

  43: }

 

Welchen Ansatz verfolgt ihr?

Fragen oder Feedback könnt ihr mir gerne als Kommentar hinterlassen.

Lazy Loading mit IoC

Update vom 04.09.2013: Beachtet bitte die Kommentare. Das Lazy-Feature kann auch erhebliche Performance-Einbußen zur Folge haben. Es kommt darauf, was der Konstruktur des Lazy-Objekts noch an Abhängigkeiten hat und welche Logik in selbigem noch ausgeführt wird.

In diesem Webcast zeige ich welche Möglichkeiten Castle.Windsor für das Lazy Loading von Abhängigkeiten bietet. Das Feature wurde in Version 3 eingeführt. Weiterführenden Inhalt welche Performance Gedanken dahinter stecken und wann idealerweise der Graph des Container geladen werden sollte, findet ihr hier und hier.

Für diejenigen, die einen anderen Container nutzen: Falls euer Framework die Funktionalität nicht out-of-the-box mitliefert, so stellt sich eine eigene Lösung nicht als allzu schwierig heraus. In dem oben zuletzt erwähnten Link gibt es dazu ein Code Sample.

Als grobe Richtlinie kann man sich merken:

Das Laden von weiteren Abhängigkeiten wird v.a. dann “teuer”, wenn die Implementierungen in Assemblies liegen, die noch nicht geladen wurden.

TDD as if you meant it

Als Ralf Westphal im Juli in der .NET UserGroup Rhein Neckar eine Session zu TDD as if you meant it hielt, wollten meine Karlsruhe Kollegen und ich uns das nicht entgehen lassen. Neue Denkansätze zu TDD als state-of-the-art Praktik sind für mich persönlich aktuell ein Dauerthema, da ich immer noch Potential nach oben sehe.

Als Vorbereitung las ich die zugehörige Artikelserie aus der dotnet pro. Ich will jetzt nicht das dort Geschriebene kommentieren oder gar hier ausführen, denn als .NET Developer haben hoffentlich die meisten Zugriff auf den Inhalt. Stattdessen hier kurz die Punkte, die für mich nochmal klarer wurden:

 

• Für TDDaiymi wird eine feststehende API benötigt, d.h. im Vorhinein muss der Contract stehen
• TDDaiymi hilft dann dabei die Aspekte innerhalb der Klasse zu identifizieren, sprich die innere Struktur wird entwickelt
• TDDaiymi ist (zeit-)aufwendiger als “klassisches” TDD und bietet sich v.a. bei komplexen, ggf. nicht gänzlich durchdrungenen Problemen an
• Als Praktik ist es sicherlich für Coding Dojos interessant, da man für saubere Aspekttrennung und implizite Annahmen (die nicht implizit sein sollten) sensibilisiert wird

 

Das Video habe ich nachbearbeitet, um die Ton- und Bildqualität zu steigern, allerdings ist es zugegebenermaßen nicht optimal. Danke an Ralf nochmal für den Vortrag und die Freigabe des Videos. Den Code gibt es ähnlich in der dotnet pro. Wenn jemand schon Erfahrungen mit der Praktik gesammelt hat, dann würde ich mich über Feedback freuen.

YouTube

Entity Framework Webcasts – Testing

Im siebten Teil meiner Entity Framework Webcast Serie widme ich mich dem Thema Testing. Zunächst nehmen wir uns die fertigen Queries vor, welche sich auch gut ohne Datenbank testen lassen. Schließlich will nicht jeder zum Testen einer Abfrage immer eine entsprechende Datenbank hochfahren und die Daten dafür erzeugen.

Danach stellen wir in einem Mini-Business-Pseudo-Layer ein Szenario nach, welches uns dedizierte Daten für die weitere Verarbeitung liefert, sodass das Testen der Geschäftslogik ebenfalls ohne Datenbank erfolgen kann.

Als BDD Framework für die Unit Tests verwende ich Machine.Specifications und als Mocking Framework kommt FakeItEasy zum Einsatz.

Hier noch die zwei Code Beispiele:

 

Beispiel 1: Testen der Query

   1: [Subject(typeof(GetAddressByCity))]

   2: public class When_addresses_contains_exactly_one_matching_entry

   3: {

   4:     static GetAddressByCity Sut;

   5:     static List<Address> Addresses;

   6:     static Address Actual;

   7:     static Address TestCity;

   8:  

   9:     Establish context = () =>

  10:     {

  11:         TestCity = new Address {City = "test city"};

  12:         Addresses = new List<Address>

  13:         {

  14:             new Address {City = "Karlsruhe"},

  15:             TestCity

  16:         };

  17:         Sut = new GetAddressByCity("test city");

  18:     };

  19:  

  20:     Because of = () =>

  21:     {

  22:         Actual = Sut.Execute(Addresses.AsQueryable());

  23:     };

  24:  

  25:     It should_return_exactly_this_address = () => 

  26:             Actual.ShouldEqual(TestCity);

  27: }

 

Beispiel 2: Testen von Geschäftslogik

   1: class EmployeeBusinessLogicSpecs

   2: {

   3:     [Subject(typeof(EmployeeBusinessLogic))]

   4:     class When_hire_date_is_unknown

   5:     {

   6:         static IUnitOfWork Uow;

   7:         static EmployeeBusinessLogic Sut;

   8:         static Employee DummyEmployee;

   9:  

  10:         Establish context = () =>

  11:         {

  12:             DummyEmployee = new Employee {EmployeeID = 1, 

  13:                     FirstName = "Uli", LastName = "Armbruster"};

  14:  

  15:             Uow = A.Fake<IUnitOfWork>();

  16:  

  17:             A

  18:                 .CallTo(() => Uow.ExecuteQuery(

  19:                     A<GetEmployeeById>

  20:                     .That

  21:                     .Matches(q => q.EmployeeId == DummyEmployee.EmployeeID)

  22:                                   ))

  23:                 .Returns(DummyEmployee);

  24:  

  25:             Sut = new EmployeeBusinessLogic(Uow);

  26:         };

  27:  

  28:         Because of = () => Sut.EnsureValidHireDate(DummyEmployee.EmployeeID);

  29:  

  30:         It should_update_it = () => DummyEmployee.HireDate.ShouldNotBeNull();

  31:  

  32:         It should_save_the_changed_hire_date = () => A

  33:             .CallTo(() => Uow.Commit())

  34:             .MustHaveHappened(Repeated.Exactly.Once);

  35:     }

  36: }

 

Entity Framework – Teil 7 – Testing – YouTube

 

Weitere Quellen:

• Alle Teile meiner Blog Serie
• Alle Teile meiner Webcast Serie
• Den Code auf GitHub
• Mein YouTube Channel

TDD 2.0

Ralf Westphal schreibt in seinem Artikel Ab ins Grüne in der dotnet pro Ausgabe 04/2013 über die Probleme mit TDD. Auf den Punkt gebracht, schildert er seinen Eindruck, dass die Fokussierung auf T(est)D(riven) einen Lösungsansatz perpetuiert hat, der D(evelopment) zu wenig bis gar nicht integriert. Will heißen: Durch die Konzentration auf das Schreiben und Lösen der Tests, wird die Analyse- und Lösungsphase fast gänzlich außer Acht gelassen. Deshalb stünden, so seine Meinung, in Coding Dojos am Ende auch nur selten fertige Ergebnisse.

Aus meiner Sicht trifft Ralf damit voll ins Schwarze. Persönlich störte ich mich seit längerer Zeit an diesem Problem. Ich denke sogar, dass das Development der weit schwierigere Teil ist. Test zu schreiben und den Code dafür entsprechend zu präparieren ist eine Art Training wie das Lösen von Gleichungen 2ter Ordnung in der Schule. Je nach Kenntnisstand des Entwicklers werden noch Vereinfachungen oder schnellere Lösungsansätze wie die binomische Formel erkannt. Ein solides Level stellt sich allerdings nach relativ kurzer Zeit ein. Neue Probleme wie Gleichungen vierter Ordnung bedürfen aber der analytische Fähigkeiten.

Deshalb haben wir bei unseren Coding Dojos die Anregungen aufgegriffen und implementiert. Interessanterweise, was ich persönlich als sehr positiv empfinde, gab es im ersten Dojo mit dem neuen Verfahren keine einzige Codezeile, da eine Stunde lang das Problem eruiert und Begrifflichkeiten diskutiert wurden. Wohlgemerkt handelte es sich dabei um ein echtes Szenario aus einer unserer Problemdomäne, d.h. wir verwendeten keine der üblichen Katas. Umso schneller kamen wir dann im zweiten Training zu einer fertigen Lösung. Mit ein wenig Überziehung erreichten wir nach 1.15h die Ziellinie.

TDD 2.0 empfinde ich als längst überfällige Erweiterung bzw. Kritik. Wir werden in Zukunft auf diese Weise weiterarbeiten. Ein Punkt, der für mich allerdings weiterhin in Frage gestellt werden sollte: Müssen Coding Dojos an Katas durchgeführt werden? Warum nicht an einem echten, auf ein notwendiges Minimum reduzierten Praxisbeispiels aus der Problemdomäne trainieren? Oder alternativ für die Administration ein kleines Hilfsprogramm schreiben, dass die tägliche Arbeit automatisiert? Kürzlich half ich meinem ehemaligen Fussballverein beim Realisieren des DFB Reglements bzgl. Stammspieler. Gelöst habe ich es vorerst über Excel, sodass immer noch Handarbeit seitens des Vorstands notwendig ist. Doch dieses Thema kommt auf unsere Coding Dojo Agenda. Es gibt viele gemeinnützige Organisationen oder Sportvereine, die sich über Hilfe der IT zu kleinen Wehwehchen freuen würden!

Entity Framework Webcasts – Stored Procedures und SQL Queries

Im sechsten Teil meiner Entity Framework Webcast Serie zeige ich, wie die IUnitOfWork erweitert werden muss, um SQL Abfragen und Befehle auszuführen. Im Fokus stehen Value Functions und Stored Procedures.

 

Entity Framework – Teil 6 – Stored Procedures und SQL Queries – YouTube

 

Dafür stellt das Entity Framework 2 Schnittstellen bereit:

• SqlQuery
• ExecuteSqlCommand

Ein wichtiger Hinweis an dieser Stelle, welcher eingehender in meinem Webcast erwähnt wird: Zum Ausführen einer SQL Query existieren 2 Implementierungen:

• DbContext.Database.SqlQuery<TElement>(string sql, params Object[] parameters)
• DbSet.SqlQuery(string sql, params Object[] parameters)

Der wesentliche Unterschied besteht darin, dass im ersten Fall die zurückgegebenen Entitäten nicht getrackt werden, im zweiten hingegen schon. Das ist leicht nachvollziehbar, so muss bei DbContext.Database.SqlQuery ein generischer Parameter, der den Rückgabewert darstellt, übergeben werden. Im Falle von DbSet.SqlQuery ist dies nicht nötig, schließlich befindet man sich zum Zeitpunkt der Abfrage auf einem konkreten Set an Entitäten, die über den Context aufgelöst wurden.

Meine vorgestellte Lösung geht den gleichen Weg wie die in Teil 3 beschriebenen Queries, d.h. es werden quasi SQL Query und Command Repositories angelegt, um einer Streuung innerhalb der Anwendungslandschaft entgegenzuwirken.

Schließlich noch zwei Sicherheitshinweise:

• Die SQL Befehle werden mit den Berechtigungen des Contexts bzw. des darunterliegenden Sicherheitstoken ausgeführt
• Beim Erstellen des SQL Strings sollte aus Sicherheitsgründen gegenüber Injections mit String.Format() oder alternativ mit SqlParameters gearbeitet werden.

 

I wrote this blog post as an answer of a question from the Netherlands, so I want to complete this article with a quote:

“When you execute a SqlQuery from Database, the results are never tracked by the context, even if the query returns types that are in the model an known by the context. If you do not want the results to be changed-tracked, use DbContext.Databae.SqlQuery.

Results of a DbSet.SqlQuery will be tracked by the context. Ensuring that results are change-tracked is the primary reason you would choose to use DbSet.SqlQuery over Database.SqlQuery.” (Programming Entity Framework, Page 226)

 

Weitere Quellen:

• Using DbContext in EF – Part 10 – Raw SQL Queries
• Programming Entity Framework: DbContext
• Alle Teiler meiner Webcastserie
• Mein YouTube Channel
• Alle meine Blogeinträge zum Entity Framework
• Den Code auf Github

Entity Framework Webcasts Serie

In den vergangenen Tagen gingen Teil 4 und 5 meiner Entity Framework Webcast Serie online. Außerdem ist geplant in den kommenden Tagen noch Teil 6 zu veröffentlichen. Das liegt darin begründet, dass ich verstärkt per E-Mail adressiert mit der Bitte wurde, die restlichen Teile nachzuschieben. Außerdem erhielt ich mehrfach Anfragen bzgl. diverser Schwerpunkte, die ich in zukünftigen Beiträgen aufgreifen möge. Den Bitten werde ich so weit mir möglich nachkommen.

Deshalb an dieser Stelle nochmal der Hinweis, dass man mich über die üblichen Kommunikationskanäle gerne ansprechen darf. Das ein oder andere Feedback hilft mir auch dabei mich immer wieder aufzurappeln und in der Freizeit derartigen Inhalt zu produzieren.

 

Hier ein kurzer Auszug aus einer Mail, die ich gerade erst vergangene Woche erhalten habe:

Hallo Herr Armbruster,

erstmal kompliment für die 3 m.E. sehr guten Videos. Gerne hätte ich noch mehr bzgl. Entity Framework gesehen. Die Art und Weise wie die Thematik erläutert wird, ist Ihnen sehr gut gelungen.

Schön wäre z.B. noch:

– Genaue Erläuterung der Konfigurationsdatei

– WCF in Verbindung mit EF

– Architekturgestaltung bis hin zur UI

Die Gestaltung und Auslagerung der Queries im Teil3 ist für mich ein riesen Lernfortschritt gewesen. Probleme habe ich jetzt bekommen, als ich die Abfrage, also eine IQuery über einen WCF Dienst laufen lassen wollte. Dieser akzeptiert ja soweit mir bekannt ist, keine generischen Typen.

Können Sie hierzu eine kurze Info geben, wie dies realisiert werden kann?

 

 

Aktuell stehen folgende 5 Webcasts in Full HD Auflösung bereit:

• Teil 1 – DbContext und POCOS: Wir wechselt man auf den neuen DbContext des Entity Framework 5 und erzeugt sich POCO Objekte frei von jeglichen Technologie-spezifischen Referenzen.
• Teil 2 – UnitOfWork und IoC: Lose Kopplung ist in diesem Beitrag das Ziel. Der Client verliert vollständig seine Abhängigkeit zum Entity Framework bzw. zur Persistenzschicht.
• Teil 3 – Queries: Hier zeige ich wie sich ein Query Repository aufbauen und Redundanz vermeiden lässt.
• Teil 4 – Eigener Kontext: Dieses Video erläutert die Implementierung eines eigenen Kontexts.
• Teil 5 – Weitere Datenbanken: Der nächste wichtiger Schritt ist das Einbinden weiterer Datenbanken. Der Vorzug hierbei ist die implizite Auflösung des entsprechenden Modells auf Basis von Konventionen.
• Teil 6 – Stored Procedures und SQL Queries: In Anlehnung an Teil 3 baue ich hier ein entsprechendes Repository für reine SQL Abfragen und Stored Procedures auf.

Der vollständige Quellcode steht in dem Repository ‘MyCleanEntityFramework’ in meinem Github Account zur Verfügung.

PostSharp & SmartInspect

Dieser Blogeintrag liefert ein paar weiterführende Informationen zu meinem zugehörigen Webcast. Darin thematisiere ich wie sich die Geschäftslogik frei von Infrastructure Code halten lässt. Eine Möglichkeit dazu bietet z.B. aspektorientierte Programmierung. Im .NET Umfeld ist PostSharp sehr gut geeignet. In dem Webcast zeige ich wie wir durch den Einsatz in Verbindung mit einem starken Logging Framework wie SmartInspect Concerns wie Logging, Exception Handling, Performance Measuring und Tracing umsetzen.

Wer gerne den Code hätte, kann mich über die üblichen Kanäle wie Twitter und Xing anschreiben. Die SmartInspect Konfiguration sieht wie folgt aus:

AppName = UAR
Connections = tcp(caption="Hello World")
DefaultLevel = Message
Enabled = True
Level = Message
SessionDefaults.Level = Message
SessionDefaults.Active = True
SessionDefaults.Color = 0x00FF40

Webcast:

PostSharp und SmartInspect zur Reduzierung der Code Vermischung

Aktualisierung vom 11.11.12 um 13.50:

Weil die Frage nach Performance aufkam, noch kurz zwei Infos: Über SkipPostSharp=false in den Build Skripten kann PostSharp deaktiviert werden. Außerdem hat Daniel Marbach eine Analyse mit 125000 Codezeilen gemacht und der CompileTime Ovewrhead lag bei lediglich einer Sekunde.

Clean Code Series – Episode 1

Hier der Blogeintrag zu dem entsprechenden Video. Es geht um ein Frage eines Bekannten, der SAP Lösungen entwickelt und der von mir Vorschläge für einen Ansatz einer Problemdomäne aus seiner Praxis haben wollte.

Hier die Modalitäten:

Ausgangssituation:

· Wir haben eine Entität, beispielsweise eine Liste von Aktivitäten

· Diese Entität filtert abhängig vom angemeldeten User einige Aktivitäten und liefert den Rest an den Aufrufer zurück

· Der Filtermechanismus und die eigentliche Liste sind auf zwei Klassen aufgeteilt, die beide dasselbe Interface implementieren

· Beide Klassen hängen nur in Form einer Aufrufhierarchie voneinander ab und sind in Reihe geschaltet (Decorator)

· Der Filtermechanismus hat Abhängigkeiten zu einer Datenbankzugriffsklasse

Das schreit ja förmlich nach IoC: Zusammenbauen einer Aufrufhierarchie über Decorator, dazu ggf. weitere Abhängigkeiten auflösen.

Schön. Aber leider ist es eine schlechte Idee, konkrete Entitäten über einen IoC Container zu erzeugen.

Was also tun? Factories bauen?

Ich denke nicht, wäre es nicht geschickter, auf die Klassen das Prototype-Pattern anzuwenden?

Der IoC erzeugt dann lediglich einen Prototypen, der von den Erzeugern konkreter Arbeitslisten als Vorlage genutzt würde. Instanziierung dann folglich über prototype->clone( ).

Was denkst du?

Meine Antwort:

Für mich ist der Ansatz nicht gut modelliert. Könnt ihr das nicht in einer Klasse abbilden? Aus Sicht des Domain Driven Designs könnte man das vielleicht so implementieren:

Ihr habt eine Klasse Activities, welcher ihr beim Erzeugen die Liste alle möglichen Activities übergeben müsst. Im Konstruktor könnt ihr nach Belieben noch eine Validierung vornehmen, z.B. ob die Liste überhaupt Elemente enthält bzw. nicht null ist.

Die Gesamtmenge speichert ihr in einer privaten Variablen. Zusätzlich legt ihr ein readonly Feld für den Zugriff von außen an. Danach benötigt die Klasse nur noch Filtermöglichkeiten. In .NET würde man nur eine Methode schreiben, nämlich ApplyFilter und übergibt an diese einen Lambda Ausdruck. […] Übrigens: Wie du intern die Datenhaltung betreibst, ist dir überlassen. Ich habe es beispielsweise mit einer Liste gemacht, die wesentlich spezieller ist als Enumerable. Da könntest du sogar den Spaß in eine Textdatei wegspeichern und bei Aufruf immer wieder auslesen. Hier ist die klare Datenkapselung eingehalten. Nach außen hin sieht man eine Veröffentlichung auf Basis der sehr generischen IEnumerable Implementierung, intern verwende ich etwas sehr Spezielles.

Nach kurzer Diskussion, was ABAP hier an Möglichkeiten bietet, habe ich folgenden Vorschlag gemacht:

Clean Code Series–Episode 1

Was meint ihr?

UAC oder keine UAC – Das ist hier die Frage

Mit meinem vorherigen Blogeintrag Windows 8 ist Gift für Legacy Code kam auf Twitter eine Diskussion zu Stande, wieso denn unsere Anwendung derart hohe Berechtigungen benötigt und dass der Code doch inzwischen längst neu geschrieben worden sein sollte. Außerdem wurde eingeworfen, was Legacy Code direkt mit der UAC zu tun hätte.

Gemäß der englischen Wikipedia Ausgabe beschreibt Legacy Code unter anderem eine nicht länger unterstützte Technologie. Demzufolge ist Windows XP, als das am weitesten verbreiteten Betriebssystem nach Windows 7 ein Legacy System. Zunächst einmal hat Legacy Code nichts direkt mit der Benutzerkontensteuerung zu tun. Allerdings ist es so, dass Legacy Code in der Regel recht alt ist, weshalb er konsequenterweise eben auch nicht mehr weiterentwickelt wird. Code, welcher z.B. vor .NET entstand, würde ich in jedem Fall als Legacy bezeichnen. Selbst .NET 1.0 und 1.1 würden vermutlich die meisten von uns hier einordnen. Nun ist klar, dass vor beispielsweise 10 Jahren die Coding Conventions noch völlig andere waren. Programmkonfigurationen standen in INI-Dateien im lokalen Ausführungsverzeichnis oder die Registry musste für das ein oder andere Szenario herhalten. Demzufolge ist es vorwiegend Legacy Code, der mit der UAC Probleme macht. Das heißt nicht, dass nicht auch neuer Code nicht Schwächen aufweist, jedoch betrifft es vornehmlich alte Module.

 

Ich schätze, dass mindestens 80% der Anwendungen (z.B. die ERP-Systeme) noch entsprechende Module verwenden. Und das ist eine sehr konservative Schätzung! Holger Schwichtenberg schrieb zu Windows 7, dass noch kein Bestandteil auf .NET basiert. SAP hat nach dem, was ich von Consultants höre, noch teilweise Programmzeilen aus den 70er Jahren. Wie ich aus eigener Erfahrung weiß, ist selbst heute noch für die Datenübertragung im EDI Umfeld primär OFTP v1 im Einsatz, d.h. die Kommunikation zwischen Firmen geht mit einer überwältigenden Mehrheit über ISDN. Das zeigt, dass alte Technologien allgegenwärtig sind. Wer sich damit bisher noch nicht hat rumschlagen müssen, gehört zu den wenigen Glücklichen.

 

Wie gesagt: Nur, weil alte Software im Einsatz ist, heißt dies nicht, dass deshalb automatisch höhere Berechtigungen notwendig sind, doch leider ist das oft der Fall. Nun könnte man noch erörtern, wie es denn sein kann, dass die Codestrukturen noch nicht aktualisiert wurden. Das spielt für mich allerdings kaum eine Rolle, da wir einfach vor diesem Problem stehen.

Aber um der Sache Genüge zu tun: Projekte werden immer noch (nichts von wegen agil) in großen Firmen auf Jahrzehnte geplant, wenn man nach HP geht, läuft deren Strategie sogar auf 75 Jahre (geradezu lächerlich!). Darüber hinaus kann eine IT sich nicht einfach einmal 3-5 (oder länger) Jahre Zeit nehmen und allen alten Code migrieren. Wenn sie das täte, würde die Fachabteilung / Geschäftsleitung vermutlich den Verantwortlichen direkt vor die Tür setzen. Selbst wenn dem nicht so wäre, so käme man der Konkurrenz nicht mehr hinterher und könnte das Produkt gänzlich einstellen.

Frage an die Leser: Wer kam denn bisher gar nicht in die Berührung mit Legacy Code?

Einführung in IoC Container

In diesem Webcast biete ich einen kleinen Einstieg zur Verwendung von IoC Containern. Diese Frameworks helfen bei der Umsetzung des Inversion of Control Principle unter Einsatz von Dependency Injection. Damit ist es möglich gemeinsam an an einem Feature zu arbeiten und so den Work in Progress (WiP) zu minimieren.

• Alle Blogeinträge zu Castle.Windsor samt den im Video gezeigten Code Beispielen gibt es hier.
• Die Projekte aus dem Webcast habe ich vorübergehend hier zur Verfügung gestellt.

 

Modularisierung durch Dependency Injection

Workshop Domain Driven Design

Heute Vormittag hatte ich das ausgesprochene Vergnügen dem Workshop von Dennis Traub beizuwohnen.  Für mich persönlich immer wieder ein Klassiker und das aus gutem Grund: Egal mit welcher Sprache und auf welcher Plattform man entwickelt, die Domänensprache ist omnipotent. Wer hier nicht mitreden kann, disqualifiziert sich schon fast als ernstzunehmender Entwickler.

Nichtsdestotrotz handelt es sich um einen sehr umfassenden, teils komplexen Ansatz, dessen vorgeschlagenen Praktiken immer wieder an konkreten Fallbeispielen geübt und ggf. im Kontext von diversen Prinzipien (SRP, DRY, etc.) evaluiert werden müssen. So verwundert es auch nicht, dass Dennis mehrfach darauf hinwies, dass es mehrere Lösungen geben kann, je nachdem wie die Context Boundaries definiert sind.

Besonders gefallen hat mir der Austausch mit den anwesenden Entwicklern. Selbst vermeintlich eingefleischte Theoretiker konnten hier sicher etwas mitnehmen. Und sei es nur, dass bei einer deutschen Fachdomänensprache der entsprechende Code ebenfalls in Deutsch sein sollte! Gefüttert wurden die Diskussionen mit einfachen User Stories, die betont unspezifisch respektive fachlich fragwürdig gehalten wurden. Ganz so, wie es in der täglichen Arbeit mit dem vermeintlichen Domänen-Experte auch der Fall ist. In kleinen Gruppen wurden diese zunächst gelöst, um dann in der Runde die Ergebnisse zu konsolidieren.

Zusammenfassend ein sehr lohnenswerter Workshop, in dem ich einige Punkte mitnehmen konnte. So zum Beispiel die interessante Aussage: DDD konsequent weitergedacht führt zu CQRS. Vor allem bin ich auf die anhängende Diskussionen bzgl. dreier Artikel gespannt, welche ich dem Präsentator zur Verfügung gestellt habe. Wem ich diese später zukommen lassen soll, der kann mich gerne kontaktieren.

		Workshop Domain Driven Design DIASHOW ANZEIGEN ALLE HERUNTERLADEN

Workshop – Eine Zeitreise mit dem Desktop Teil 2

Nachdem ich in Teil 1 die aktuell zur Verfügung stehenden Technologien angesprochen habe, soll es nun mehr um Patterns und Clean Code Prinzipien schlechthin gehen.

Während WinForms mit seinem Code Behind in keinster Weise den Anforderungen an die Evolvierbarkeit von Code genügt, wurde mit WPF von Anfang an eine leichte Abwandlung des MVC/MVP Patterns “vermarktet”: Das Model View ViewModel Pattern.

Frank und Silvio stellen hierbei das Seperation of Concerns Principle in den Vordergrund. Besonders gut gefallen hat mir in diesem Kontext auch deren Haltung zu Domain Driven Design. Wie ich, haben sie eine von der ursprünglichen Lehre Evans abweichende Meinung bgzl. der Vermischung von Daten und Logik im selben Objekt. Ralf Westphal hat dies in den vergangenen 6 Monaten ebenfalls in einer 3-teiligen Serie in der dotnetpro (in den Heften 4, 6 und 7 2012) thematisiert.

Anmerkung: Auf dem im Juli stattgefundenen .NET Open Space Süd kam im Übrigen selbige Diskussion. Deshalb an dieser Stelle meine Aufforderung an die Community hierüber vermehrt zu bloggen.

Leider hat MVVM auch diverse Nachteile, darunter das häufige Wiederholen von gleichem bzw. ähnlichem Code. Nachdem kurz über diverse MVVM Frameworks gesprochen wurde, stellten die Referenten eine von ihnen entwickelte im Produktiveinsatz befindliche Lösung vor, die mit ca. 1000 Codezeilen recht überschaubar ist. Laut Aussagen haben sie sich dafür die Schmerzstellen in den eigenen Projekten angeschaut und das Beste für sich aus den verschiedenen Frameworks herausgepickt.

Den Code werde ich, nachdem die Zwei das Feedback des Workshops eingearbeitet haben, mit deren freundlicher Erlaubnis hier online stellen.

Zusammenarbeit mit der Fachabteilung – BDD und TDD helfen

Test Driven Development (TDD) steht dafür, dass Tests vor der eigentlichen Implementierung zu schreiben sind. Es zwingt den Entwickler sich vorher genaue Gedanken über die Architektur und die Implementierung zu machen, sodass “einfaches loslaufen” und ggf. damit einhergehendes “falschlaufen” vermieden wird. Saubere Codequalität wird gefördert.

Behaviour Driven Development bringt nun einen weiteren Ansatz mit ins Spiel: Code soll ergebnisorientiert getrieben sein, d.h. die fachlichen Spezifikationen stehen im Vordergrund. Entsprechende BDD Frameworks wie Machine.Specifications (Link, gibt es auch auf NuGet) unterstützen nun dabei, dieses Ziel umzusetzen.

Damit sich auch Nicht-IT-ler und weniger Test-affine Entwickler etwas darunter vorstellen können, hier ein kleines Beispiel aus der Praxis. Wir praktizieren dies bereits seit einigen Monaten in der Form mit unseren Fachabteilungen:

Aufgabenstellung: Mehrere Produktartikel sind in einer gemeinsamen Bestellmappe zusammengefasst. Diese Mappe besitzt die Kopfdaten ‘Lieferzeit’ (LZ), ‘Bearbeitungszeit’ (BZ), ‘Bestellintervall’ (BI) und ‘nächster Mappentermin’ (MT). Der nächste Mappentermin besagt, wann die Mappe sich beim zuständigen Benutzer melden, sodass dieser eine neue Bestellung auslöst. Das Bestellintervall gibt an in welchen Abständen die Mappe neu bearbeitet werden muss, z.B. alle 3 Wochen. Die restlichen Begriffe sprechen für sich. Nun wird von der Fachabteilung gefordert, dass sogenannte ‘fiktiven Wareneingänge’ (fWE) visuell dargestellt werden (siehe Screenshot). Dabei handelt es sich um Eingänge, die rein rechnerisch in der Zukunft eingehen würden, wenn die Bestellungen so getätigt würden. Also bedarf es einer Möglichkeit, um diese Termin zu berechnen.

 

 

Die Tests visualisiert für die Übergabe an die Fachabteilung:

Es handelt sich hier um 7 Tests. Der obere Abschnitt besagt:

Wenn von einer Bestellmappe die die Lieferzeit 5 Tage, die Bearbeitungszeit 1 Tag und das Bestellintervall 14 Tage sind und hierfür die nächsten 3 fiktiven Wareneingänge aus heutiger Sicht berechnet werden sollen:

• Dann sollte der erste fiktive Wareneingang in 6 Tagen sein
• Dann sollte der zweite fiktive Wareneingang in 21 Tagen sein
• Dann sollte der dritte fiktive Wareneingang in 36 Tagen sein
• Dann sollt es insgesamt 3 Datumsangaben errechnen

Der zweite Abschnitt ist analog zu lesen, wenn die Abkürzungen ausgeschrieben werden. Das Wesentliche daran ist, dass diese Spezifikationen von der Fachabteilungen kommen und diese so sich im Code 1 zu 1 widerspiegeln. Damit können die Entwickler die Brücke schlagen und sich mit den Anwendern in deren Domänensprache unterhalten. Die Spezifikationen garantieren, dass der Code sich wie gewünscht verhält. Die Tests lassen sich automatisiert wiederholen und werden vor jeder neuen Versionsauslieferung durchlaufen.

 

 

Zur Gänze folgen noch der Code für die Tests und die eigentliche Implementierung:

Der Code für die Tests:

   1: [Subject("Fiktive Wareneingänge")]

   2: public class Wenn_von_einer_Mappe_die_LZ_5T_die_BZ_1T_und

   3: _das_BI_14T_sind_und_3_fWE_ab_heute_berechnet_werden_sollen

   4: {

   5:     Establish context = () =>

   6:     {

   7:         Clock = new DummyClock();

   8:         Folder = new OrderProposalFolder { DeliveryPeriodInDays = 5, 

   9:                 HandlingTimeInDays = 1, OrderIntervalInDays = 14 };

  10:         Sut = new FictitiousIntakes(Clock);

  11:     };

  12:  

  13:     Because of = () =>

  14:     {

  15:         Actual = Sut.FromNow(Folder, 3);

  16:     };

  17:  

  18:     It dann_sollten_exakt_3_Datumsangaben_errechnet_werden = () => Actual.Count.ShouldEqual(3);

  19:     It dann_sollte_der_erste_fWE_in_6T_sein = () => Actual.Min().ShouldEqual(Clock.Today.AddDays(6));

  20:     It dann_sollte_der_zweite_fWE_in_21T_sein = () => Actual.ElementAt(1).ShouldEqual(Clock.Today.AddDays(21));

  21:     It dann_sollte_der_dritte_fWE_in_36T_sein = () => Actual.Max().ShouldEqual(Clock.Today.AddDays(36));

  22:  

  23:     static FictitiousIntakes Sut;

  24:     static OrderProposalFolder Folder;

  25:     static IList<DateTime> Actual;

  26:     static IClock Clock;

  27: }

  28:  

  29: [Subject("Fiktive Wareneingänge")]

  30: public class Wenn_von_einer_Mappe_die_LZ_5T_die_BZ_1T_und_das_BI_14T_sind_

  31: und_der_nächste_MT_übermorgen_ist_und_2_fWE_ab_dem_nächsten_MT_berechnet_werden_sollen

  32: {

  33:     Establish context = () =>

  34:     {

  35:         Clock = new DummyClock();

  36:         Folder = new OrderProposalFolder {NextOrderDate = Clock.Now.AddDays(2) ,DeliveryPeriodInDays = 5,

  37:                                          HandlingTimeInDays = 1, OrderIntervalInDays = 14 };

  38:         Sut = new FictitiousIntakes(Clock);

  39:     };

  40:  

  41:     Because of = () =>

  42:     {

  43:         Actual = Sut.FromNextFolderDate(Folder, 2);

  44:     };

  45:  

  46:     It dann_sollten_exakt_2_Datumsangaben_errechnet_werden = () => Actual.Count.ShouldEqual(2);

  47:     It dann_sollte_der_erste_fWE_in_8T_sein = () => Actual.Min().ShouldEqual(Clock.Today.AddDays(8));

  48:     It dann_sollte_der_dritte_fWE_in_23T_sein = () => Actual.Max().ShouldEqual(Clock.Today.AddDays(23));

  49:  

  50:     static FictitiousIntakes Sut;

  51:     static OrderProposalFolder Folder;

  52:     static IList<DateTime> Actual;

  53:     static IClock Clock;

  54: }

 

Der produktive Code, der im Programm zur Berechnung verwendet wird:

   1: public class FictitiousIntakes : ICalculateFictitiousIntakes

   2: {

   3:     readonly IClock _clock;

   4:  

   5:     public FictitiousIntakes(IClock clock)

   6:     {

   7:         _clock = clock;

   8:     }

   9:  

  10:     public IList<DateTime> FromNow(OrderProposalFolder folder, int toOrdinal)

  11:     {

  12:         return FromThis(_clock.Today, folder, toOrdinal);

  13:     }

  14:  

  15:     public IList<DateTime> FromNextFolderDate(OrderProposalFolder folder, int toOrdinal)

  16:     {

  17:         return FromThis(folder.NextOrderDate, folder, toOrdinal);

  18:  

  19:     }

  20:  

  21:     private IList<DateTime> FromThis(DateTime startDate, OrderProposalFolder folder, int toOrdinal)

  22:     {

  23:         if (toOrdinal < 1)

  24:             throw new ArgumentOutOfRangeException("toOrdinal");

  25:  

  26:         var firstIntake = startDate.AddDays(folder.DeliveryPeriodInDays + folder.HandlingTimeInDays);

  27:  

  28:         var result = new List<DateTime>();

  29:         for (int currentOrdinal = 0; currentOrdinal <= toOrdinal - 1; currentOrdinal++)

  30:             result.Add(firstIntake.AddDays(currentOrdinal * 

  31:                     (folder.OrderIntervalInDays + folder.HandlingTimeInDays)));

  32:  

  33:         return result;

  34:     }

  35: }

NServiceBus – Auf Tuchfühlung

Heute hatte ich meinen ersten Kontakt mit NServiceBus, nachdem ich mir in einigen Stunden das Konzept zu Gemüte geführt hatte. Primär dienten mir dazu die zwei Udi Dahan Videos. Da ich sehr begeistert davon war, habe ich sogleich einen Webcast erstellt. Persönlich denke ich, dass NServiceBus im .NET Umfeld durchaus in der Technologie-Evaluierung einbezogen werden sollte, wenn es um asynchrone und langlaufende Prozesse (sogenannte Sagas) geht. NServiceBus ist in gewissem Rahmen kostenfrei und steht als NuGet Package zur Verfügung. Die eigentliche Installation läuft sehr leicht von der Hand, da (wie man es selbst auch mit TopShelf bewerkstelligen kann) die erzeugte EXE für den Host bereits sämtliche Logik zur Installation enthält.

Für die Erstinstallation einfach den Parameter /installInfrastructure anhängen. Hier die Auflistung sämtlicher Parameter, die besagter Host enthält:

 

Besonders hervorzuheben ist die Tatsache, dass es NServiceBus absichtlich erschwert eine schlechte Architektur zu implementieren. So erhält der Client beim Verschicken eines Commands über Bus.Send lediglich als Rückgabewert ein ICallback Object, das es lediglich ermöglicht auf Fehler zu prüfen. Damit ist man gezwungen separat eine entsprechende Logikeinheit zu implementieren, die zur Verarbeitung des Events dient.

Gleichfalls wird quasi dazu eingeladen Code mit transaktionalem Verhalten in einer UnitOfWork unterzubringen und IoC zu verwenden.

Weitere nette Features:

• Fluent API
• Fördern des Convention over Configuration Principles
• Trennung von Admin und Developer Verantwortungsbereichen
• Eingebauter IoC Container (AutoFac)
• Schnelle DB in Form von RavenDB mitgeliefert
• Sinnvoll Benamsung wie IWantCustomInitialization
  

Das sind nur einige Punkte, die mir gefallen!

 

Für mich wären jetzt 2 weitere wesentliche Schritte:

• Eigenen IoC Container einhängen, wie hier gezeigt (sehr elegant!)
• Konfiguration der Clients im Code, um die Config beispielsweise aus der DB beim Bootstrapping zu lesen. Dies ist wohl nicht ganz trivial bzw. nicht angedacht (falls doch, bitte Info an mich!)

MVVM & WPF auf dem Prüfstand–Teil 2

In meinem ersten Beitrag habe ich bereits einige wesentliche Punkte genannt, die es zu evaluieren gilt. Beim Hackathon konnte ich langjährige und erfahrene Entwickler im WPF-MVVM-Bereich darauf ansprechen. Zunächst einmal ist der Grundgedanke weiterhin der, dass zu prüfen ist, ob man die Vorteile von MVVM überhaupt nutzt. Falls dem nicht der Fall ist, bedeutet das nicht notwendigerweise, dass deshalb MVVM ausscheiden muss. Dem liegt die Prämisse zu Grunde, dass die Komplexität und konsequenterweise die damit einhergehende Development Velocity nicht weniger produktiv (d.h. betriebswirtschaftlich rentabel) ist, als wenn ich beispielsweise mit Code Behind arbeiten würde. Hier sind 3 wesentliche Punkte zu nennen:

• Data Binding: Dies ist sicherlich deutlich schwieriger mit Code Behind zu implementieren
• Designer Workflow: Expression Blend fällt bei Code Behind in jedem Fall aus. Da Expression Blend deutlich schneller als der VS Designer ist und darüber hinaus Unterstützung für Modellierung mit Live Daten bietet, ist hier mit Sicherheit mit Zeiteinsparungen zu rechnen.
• Team Arbeit: Durch den Einsatz eines verbreiteten, standardisierten Patterns gestaltet sich die Zusammenarbeit einfacher und vermutlich auch effektiver. Ein neuer Developer, der das Pattern kennt, dürfte auch schneller einzuführen sein.

Trotzdem gilt zu bedenken, dass ohne entsprechende Dritthersteller-Frameworks wie Caliburn.Micro, die einem das Groß an Infrastruktur Programmierung abnehmen, nur selten effektiver und somit rentabel gearbeitet werden kann. Wer auf Grund der Rahmenbedingungen hierauf verzichten muss, sollte sich also überlegen, ob MVVM für ihn sinnvoll ist. Es sei aber auch angemerkt, dass mit relativ einfachen Mitteln entsprechende Funktionalität selbst implementiert werden kann.

MVVM & WPF auf dem Prüfstand

Wer mit dem Gedanken spielt die WPF in Verbindung mit dem MVVM Pattern einzusetzen, sollte zunächst kurz stehen bleiben und überlegen, was er erreichen will:

• Will ich die Oberfläche automatisiert testen
• Will ich die UI austauschen und z.B. eine zusätzliche Webschnittstelle mit HTML zur Verfügung stellen
• Will ich gleichzeitig an der UI designen und am Code entwickeln können, z.B. durch ein Marketing und ein Entwickler Team

Das sind die 3 wesentlichen Akzeptanztests, die den Ausschlag für oder gegen WPF und MVVM geben.

Wer keine Tests schreiben will, der verliert bereits einen wesentlichen Punkt, denn der Grundgedanke hinter MVVM war besagtes Testen. Persönlich würde mich interessieren wie viele MVVM einsetzen und dementsprechend die Tests schreiben. Diejenigen, die lediglich mit Wechselgedanken spielen, denen könnte man empfehlen sich die Testabdeckung für die Geschäftslogik anzuschauen. Ist diese sehr moderat bis hin zu gänzlich fehlend, so ist nicht davon auszugehen, dass der Punkt umgesetzt werden würde.

Bleibt die lose UI Kopplung als weiterer Punkt. Sicherlich nicht unwichtig, bedenkt man, dass webbasierter und mobiler Zugang zu Applikationen ganz sicher die Zukunft gehört. Bestes Zeichen hierfür: Neue Windows 8 Apps können nur noch mit XAML oder HTML5 entwickelt werden. Allerdings könnte in diesem Fall, um zwei Alternativen zu nennen, vielleicht auch auf ASP.NET mit MVC oder auf WPF mit Code Behind gesetzt werden.

Der letzte und für mich persönlich mindestens genauso wichtige Akzeptanztest ist die Möglichkeit Designer an die Oberfläche zu setzen, während man als Entwickler seinem Hauptgeschäft nachgehen kann: Geschäftsprozesse implementieren und optimieren. Was hier bereits mit Expression Blend oder ähnlichen Tools bereits möglich ist, kann ich nicht sagen, allerdings finde ich den Gedanken charmant! Nero hatte hierzu einmal einen Praxisbericht gegeben – damals noch mit Version 2 von Expression. Falls dies ein Entwickler aus Karlsbad liest: Wie ist der aktuelle Stand? Wie ich allerdings bei mir im Betrieb feststellen musste, sind die Hemmnisse – sowohl auf Seiten der Designer in der Marketingabteilung, als auch auf Seiten der Entwicklerkollegen – hier noch recht hoch. Primär wird daran gezweifelt, ob dies technisch überhaupt ohne größere Schwierigkeiten funktioniert (Stichwort Mock-Daten) und ob man als Entwickler dieses Mittel der Steuerung aus der Hand geben sollte. Inwieweit weniger IT-affine Designer überhaupt dazu in der Lage wäre, steht auch einer anderen Seite.

Sind alle 3 Punkte zu verneinen, so rechtfertigt der Mehraufwand und der Einkauf von Komplexität sicherlich nicht den Einsatz. In diesem Fall kann man – ohne sich schämen zu müssen – durchaus auch über WPF mit Code Behind nachdenken.

Webcast Strategy Pattern mit IoC

Den Webcast zu diesem Blogeintrag gibt es hier.

Strategy Pattern mit IoC sauber implementiert

Ein kurzer Hinweis vorab: Den Inhalt des Blogeintrags habe ich auch in einem Webcast zusammengefasst. Das Video gibt es auf YouTube. Den Code findet ihr hier.

In meinem letzten Blogeintrag habe ich das Strategy Pattern in der Praxis gezeigt. Primär gab es noch einen Smell, welchen ich erwähnt hatte: Das Open Closed Principle ist damit noch nicht 100%ig eingehalten und an einer Stelle heble ich mein IoC Konzept aus. Das passiert genau hier:

   1: public StateHandler(IClock clock, IBuildDefaultProposalsValues defaultValues)

   2: {

   3:     Handler = new Dictionary<SelloutStates, ICreateOrderProposal>

   4:               {

   5:                   {SelloutStates.Oversupply, null},

   6:                   {SelloutStates.Predicted, new PredictedGap(defaultValues)},

   7:                   {SelloutStates.Urgent, new UrgentGap(defaultValues, clock)},

   8:                   {SelloutStates.AppointmentWarnings, new AppointmentWarning(defaultValues, clock)},

   9:                   {SelloutStates.Unknown, null},

  10:                   {SelloutStates.Verify, new NoForecastPossible(defaultValues)},

  11:                   {SelloutStates.Ok, new UncomplicatedAppointment(defaultValues, clock)}

  12:               };

  13: }

Zum einen müsste ich die Klasse immer anpassen, wenn ich einen weiteren Status aufnehmen möchte. Zum anderen erzeuge ich mir Instanzen von Klassen, welche ich nicht über den Container erhalten habe, sprich ich hole mir die Abhängigkeiten selbst, statt mir diese gemäß Inversion of Control Principle zuweisen zu lassen. Das wäre zwar möglich gewesen, allerdings würde der Konstruktor dadurch erheblich aufblähen, weil ich pro Status eine Implementierung reinreichen müssten. Dieses Problem könnte ich über Service Location lösen, d.h. ich lasse mir lediglich den Container reinreichen und mache die Auflösung intern. Für mich persönlich auch keine schöne Lösung (Hinweis: Dafür müsste man den Container in sich selbst registrieren…).

Ob nun saubere Dependency Injection mit aufgeblähtem Konstruktor oder Service Location, in jedem Fall bliebe das Problem, dass ich jedes Mal im Container eine weitere Registrierung für einen neuen Status durchführen müsste.

Daraufhin kamen Rückfragen, wie dies am besten zu lösen sei. Das soll Thema dieses Blogeintrags und des dazu passenden Webcasts sein, v.a. weil im Netz auch nur selten saubere Implementierungen anzutreffen sind, die alle Prinzipien einhalten.

Als erstes wird der obere Code gänzlich entfernt, da dieser nicht mehr benötigt wird. Hinter dem Code steckte eigentlich das Factory Pattern. Ich lasse mir durch die Factory (abhängig vom Status) das entsprechende Objekt erzeugen und arbeite dann mit diesem weiter. Castle.Windsor als IoC Container bietet uns hierfür sogenannte interface-based factories an.

Anmerkung: Der folgende Code basiert nicht mehr auf dem bisherigen, welchen ich im vorherigen Blogeintrag verwendet habe. Im Webcast ist dazu alles erläutert und ich habe das Projekt unter Github zur Verfügung gestellt.

   1: yield return Component

   2:     .For<IchVermittleVorschlagsrechner>()

   3:     .AsFactory(c => c.SelectedWith(new VorschlagsrechnerVermittler()));

Wie man sieht, muss man lediglich das Factory-Interface, welches man zuvor selbst ausimplementiert hatte, angeben und im Anschluss ‘AsFactory’ anhängen. Als Parameter übergebe ich den Verweis auf eine Logik, welche die Factory später intern verwendet, um mir das korrekte Objekt (den korrekten Service) zurückzuliefern. Das Bedeutet, dass “new VorschlagsrechnerVermittler” der Factory, wenn auf ihr ein Aufruf stattfindet, sagen muss, was sie zurückgeben soll. Es folgt die Implementierung:

   1: public class VorschlagsrechnerVermittler : DefaultTypedFactoryComponentSelector

   2: {

   3:     protected override string GetComponentName(MethodInfo method, object[] arguments)

   4:     {

   5:         if (method.Name == "Für" && arguments.Length == 1 && arguments[0] is Bestandsstatus)

   6:         {

   7:             var status = arguments[0].ToString();

   8:             //von mir frei gewählte Konvention wie die Komponente im Container heißt

   9:             return string.Format("BerechnerFürArtikelstatus{0}", status);

  10:         }

  11:         return base.GetComponentName(method, arguments);

  12:     }

  13: }

Dieser Code macht nun genau das, was ich vorher explizit im Dictionary definiert habe, allerdings anhand einer Konvention. Die Methode in Zeile 3 liefert als String den Namen der Komponente zurück basieren auf dem Namen des Status, also z.B. ergibt sich für den Status “Ok” der Komponentenname “BerechnerFürArtikelstatusOk”.

Nun fehlt lediglich noch eine kleine Anpassung für den IoC Container. Dieser weiß bisher nichts von einer Komponente “BerechnerFürArtikelstatusOk”. Eine Möglichkeit wäre, dass ich – wie bereits eingangs erwähnt – für jeden Status die Ausprägung im Container registriere, also in diesem Fall beispielsweise so:

   1: yield return Component.For<IchErrechneArtikelZukaufsvorschlag>()

   2:     .ImplementedBy<Ok>()

   3:     .Named("BerechnerFürArtikelstatusOk")

   4:     .LifestyleTransient();

Das widerspricht immer noch dem OCP, sodass ich es wie folgt löse:

   1: yield return AllTypes.FromThisAssembly()

   2:     .BasedOn<IchErrechneArtikelZukaufsvorschlag>()

   3:     .Configure(a => a.Named(string.Format("BerechnerFürArtikelstatus{0}",

   4:         a.Implementation.UnderlyingSystemType.Name)))

   5:     .Configure(a => a.LifestyleTransient());

Zunächst hole ich mir alle Klassen aus der aktuellen Assembly, welche auf “IchErrechneArtikelZukaufsvorschlag” basieren, also alle meinen konkreten Status-Implementierungen. Im Anschluss sage ich noch, welchen Name diese Komponenten im Container bekommen sollen. Hier steht die selbe Konvention wie in dem Code Sample  zuvor. Der Vollständigkeit halber sei erwähnt, dass ich hier gegen das Don’t Repeat Yourself Principle verstoße. Dies soll lediglich der Vereinfachung im Beispiel dienen.

Ab jetzt muss ich, wenn ein weiterer Status hinzu kommt, lediglich eine Implementierung für diesen machen. Bestehender Code muss nicht mehr angefasst werden.

Clean Code Sample

In einem Gespräch mit unseren Webentwicklern habe ich den Kollegen einen Vorschlag für die Implementierung des Zugangs zu unserem Kundenportals unterbreitet: Unsere PHP Entwickler sind inzwischen ebenfalls auf den Ansatz des Testens umgestiegen, sodass sie ihre PHP und JavaScript Architektur anpassen müssen. Leider fehlt es an Frameworks, die einem ein Teil der Arbeit abnehmen könnten, wie z.B. Mocking Frameworks a la FakeItEasy. Falls jemand Frameworks kennt, dann melde er sich bitte bei mir.

Anforderungen (vereinfacht): An unserem Kundenportal ‘MyHeco’ soll man sich einloggen, ausloggen und das Password zurücksetzen können. Die Webanwendung konsumiert dabei .NET basierende Webservices!

Dies soll nun möglichst clean unter Einhaltung gängiger Prinzipien (wie z.B. dem Single Responsibility Principle) umgesetzt werden. Wie bereits erwähnt, muss die Architektur so gewählt werden, dass der Code einfach zu testen ist. Das ist v.a. auch deswegen nicht ganz trivial, weil Aufrufe nach ‘Außen’ zu Webservices gehen.

Hier also mein Vorschlag (natürlich in C# formuliert):

   1: interface IAuthenticateMyHecoUser

   2: {

   3:     MyHecoUser Login(string email, string password);

   4: }

   5:  

   6: interface ILogoutMyHecoUser

   7: {

   8:     void Logout(string session);

   9: }

  10:  

  11: interface IResetMyHecoPassword

  12: {

  13:     void ResetPassword(string email);

  14: }

Schreibe 3 Interfaces für die eigentlichen Aktionen, z.B. Login. Natürlich könnte dafür auch nur ein Interface geschrieben werden werden, allerdings empfinde ich es so als sauberer und die Interfaces lassen sich sprechend benennen (ohne Weasel Words, also Füllwörter; tollen Artikel dazu gibt es von Johannes).

Danach benötigen wir ein Interface für die Webservice-Kommunikation, welches ich an dieser Stelle leer lasse:

   1: public interface IERPCommunication

   2: {

   3:      

   4: }

Was ich ebenfalls zu den Kontrakten zähle (vergleicht dazu diesen Artikel), ist das DTO MyHecoUser, welches später die gefüllten Daten zum Austausch innerhalb von PHP enthalten soll.

   1: public class MyHecoUser

   2: {

   3:     public readonly int Kundennummer;

   4:     public readonly string Session;

   5:     //und diverse weitere

   6: }

Zu guter Letzt benötigen wir noch die Implementierung, die so aussehen könnte. Je nach Umfang und Größe des Codes, wäre es auch durchaus denkbar, die Implementierung auf verschiedene Klassen aufzusplitten. Aber in diesem Fall implementiert eine Klasse die 3 Interfaces aus dem Code Snippet ganz oben.

   1: public class MyHeco : IAuthenticateMyHecoUser, ILogoutMyHecoUser, IResetMyHecoPassword

   2: {

   3:     readonly IERPCommunication _webservice;

   4:  

   5:     public MyHeco(IERPCommunication webservice)

   6:     {

   7:         _webservice = webservice;

   8:     }

   9:  

  10:     public MyHecoUser Login(string email, string password)

  11:     {

  12:         throw new System.NotImplementedException();

  13:     }

  14:  

  15:     public void Logout(string session)

  16:     {

  17:         throw new System.NotImplementedException();

  18:     }

  19:  

  20:     public void ResetPassword(string email)

  21:     {

  22:         throw new System.NotImplementedException();

  23:     }

  24: }

 

Durch die Abstraktion der Webservice-Kommunikation hinter einem Interface und dem Injizieren im Konstruktor, können die Kollegen nun für den Test einen selbstgeschriebenen Fake hineinreichen. Ich validiere hier zugegebenermaßen den Parameter nicht, da ich in unserer Architektur auf IoC mit Castle.Windsor setze. Die Benennung spricht mich persönlich auch an, da sie sehr aussagekräftig ist:

MyHeco.Login oder Myheco.Logout sind eindeutig. Die Kohäsion scheint mir ebenfalls recht hoch, da die 3 möglichen von der Fachabteilung definierten MyHeco Aktionen in einer Klasse gekapselt sind. Trotzdem wäre eine spätere Auftrennung sehr einfach, da in der konsumierenden Klasse nur das konkrete Interface reingegeben wird. Beispiel: In einer Bestellung muss sich der Kunde erst einloggen. Also bekommt die Logik für eine Bestellung im Konstruktor ein IAuthenticateMyHecoUser reingereicht. Ist in Zukunft die Implementierung nicht mehr in der Klasse MyHeco, ändert sich die Logik der Bestellung in keiner Weise.

Universal Service Host

Ich habe soeben in meinem Github Repository ein Projekt zur Verfügung gestellt, mit welchem ihr euch sehr einfach NT Dienste basteln könnt. Einfach das Interface “IAmService” aus der Contracts Assembly in eurem Projekt implementieren und mit Castle.Windsor das Ganze im IoC-Container registrieren und schon könnt ihr euer Programm als Dienst bereitstellen. Das geht im Übrigen auch für eine beliebige Anzahl an Diensten, solange die DLLs dazu im gleichen Verzeichnis wie die EXE-Datei liegen.

Hier ein Video, in dem ich alles erkläre:

Entity Framework Webcasts – UnitOfWork und IoC

 

Ich habe auf YouTube mit einer Webcast Reihe zum Entity Framework begonnen. Ich stelle dabei einen Lösungsansatz vor, der zum Ziel hat das EF in der Anwendungsarchitektur als Persistenzschicht derart zu integrieren, dass Unit und Integration Tests einfach zu implementieren sind. Darüber hinaus soll der Ansatz gängige Prinzipien wie Inversion of Control (IoC), Single Responsibility Principle (SRP), Open-Closed-Principle (OCP) umsetzen, sowie die Abhängigkeiten zum Framework minimieren.

In diesem zweiten Teil zeige ich wie man durch den Einsatz eines IoC-Containers eine direkte Abhängigkeit zur Persistenzschicht vermeiden kann. Darüber hinaus setze ich hier bereits das Konzept einer UnitOfWork ein, welche ich in einem folgenden Teil näher erläutern werde.

Entity Framework – Teil 2 – UnitOfWork und Inversion of Control
– YouTube

Quellen:

• Alle Blogeinträge zu Castle.Windsor
• Code für den Bootstrapper
• Artikel von Scott Allen zum Thema UnitOfWork und Repository Pattern
• Inversion of Control Artikel
• Mein YouTube Channel
• Alle meine Blogeinträge zum Entity Framework