Option-Types & ASP.NET Web API

Vor einigen Tagen habe ich den Artikel A tale of nulls von Steffen Forkmann über die Behandlung von Null-Values gelesen.
So wurde ich auf die Option-Types aufmerksam, mit denen explizit das Verhalten einer Anwendung modelliert werden kann, wenn eine Methode eine leere Ergebnismenge (also null) zurückgibt.

Für erste  Tests habe ich auf GitHub ein Repository angelegt, um die Monad-Struktur auszuprobieren: GitHub http://goo.gl/Kvq00
In diesem Repository befindet sich im Verzeichnis WebApi.Example ein Anwendungsfall bei der Verwendung der ASP.NET Web-API.

Demo

Im folgenden sind zum Vergleich zwei Implementierungen einer Controller-Action zu sehen, die einen GET-Request entgegennehmen.

Es wird ein Kunde (customer) aus einem Repository geladen. Sollte kein Kunde mit der entsprechenden ID gefunden worden sein, wird ein HTTP-Error 404-Not Found erstellt.
Anderen Falls wird der Kunde an den Client zurückgegeben.

Ohne Option-Types

+Die Action ist schnell implementiert.
 Durch die Prüfung auf null entsteht Code-Smell.
Das durch die If-Abfrage entstehende Nesting macht den Code schlecht lesebar.
Es ist nötig eine zusätzliches Objekt vom Typ HttpResponseMessage  zu deklarieren, um diese, je nach Ergebnis der Abfrage, zu initialisieren.

Mit Option-Types

In diesem Fall liefert das Repository das Objekt Customer nicht direkt zurück, sondern als IOption<Customer>. Mithilfe der Erweiterungsmethode Match kann modelliert werden, was die Web-Api zurückgeben soll, wenn ein Kunde gefunden wurde und wie sie sich bei einer leeren Ergebnismenge verhalten soll.

+ Die explizite Prüfung auf null wird in der Controller-Action vermieden.
+ Der Null-Check kann also auch nicht vergessen werden.
+ Die Verarbeitung von Null-Werten ist explizit modelliert
+ Dadurch wird die Anwendung meiner Meinung nach robuster.
+ Außerdem wird der Quellcode der Controller-Action lesbarer.
Aufwendigere Implementierung
* Verständnis zu Option-Types muss vorhanden sein

Fazit

Ich bin ein absoluter Neuling, wenn es um Konzepte der funktionalen Programmiersprachen geht. Dennoch halte ich den Einsatz von Option-Types in Controller-Actions bisher für sehr elegant.

Diskussion

Wie ist eure Meinung zu meinem Vorgehen?
Setzt ihr ähnliche Muster bei der Entwicklung eurer Controller-Actions ein?

Über Fragen und Feedback freue ich mich.

Cheers
Gregor

Gregor

Gregor Woiwode ist Angestellter der heco GmbH, wo er als Sofwareentwickler und Trainer tätig ist. Sein Fokus liegt in der Erstellung von Webportalen mit dem .NET- und Angular-Framework. Von 2007 bis 2010 studierte er Telekommunikationsinformatik an der Hochschule für Telekommunikation in Leipzig und schloss den Studiengang als Bachelor of Engineering ab. Derzeit studiert er im Studiengang Wirtschaftsinformatik um die Auszeichnung Master of Science zu erhalten.

2 thoughts on “Option-Types & ASP.NET Web API

  1. Also ich finde die erste Variante besser lesbar. Man könnte die Variable response noch einsparen, indem man return gleich in if und else schreibt. Aber ich kenne mich mit den Lambda-Ausdrücken nicht so gut aus, deswegen wirkt die 2. Variante auf mich etwas befremdlich 😉

  2. Hi Johannes,

    da hast du recht die Variable response könnte ich weglassen. Allerdings habe ich dann 2 return-Statements. Damit würde ich meiner Meinung nach gegen das DRY-Prinzip (Don’t repeat yourself) verstoßen.
    Ich glaube auch, dass die erste Variante für diejenigen lesbarer ist, die nicht aus der C#-Welt kommen.
    Eventuell habe ich den eigentlichen Mehrwert nicht richtig herausgearbeitet. In Variante 2 wird die Behandlung von NULL explizit durch die Implementierung der Option-Types garantiert.

    Ich persönlich vergesse gerne das Prüfen auf NULL, wodurch sich in meinem Programm-Code Fehler einschleichen.
    Die Option-Types haben mir geholfen dieses Problem zu lösen.

What do you think? Please leave a Comment below!