HowTo: Fluent Interfaces – schöne APIs mit C# 3.0
APIs (egal ob sie nur für interne Zwecke da sind oder auch an externe Entwicklern geht) sollten möglichst einfach und intuitiv zu bedienen sein.
Seit kurzem lese ich immer häufiger von “Fluent Interfaces“.
Was ist das denn?
Schauen wir uns einfach mal das Wikipedia Beispiel an:
public class ExampleProgram
{
[STAThread]
public static void Main(string[] args)
{
//Standard Example
IConfiguration config = new Configuration();
config.SetColor("blue");
config.SetHeight(1);
config.SetLength(2);
config.SetDepth(3);
//FluentExample
IConfigurationFluent config =
new ConfigurationFluent().SetColor("blue")
.SetHeight(1)
.SetLength(2)
.SetDepth(3);
}
Anstatt nur einzelne Methodenaufrufe zu haben, ist es doch viel angenehmer diese in “einem Satz” niederzuschreiben. Diese Technik findet auch in diversen Javascript-Bibliotheken Einsatz (z.b: jQuery)
Sieht nicht schlecht aus – wie macht man sowas?
Es gibt (wie in dem Wikipedia Beispiel) sicherlich ein paar Tricks wie man sowas machen kann – durch Rob Conerys Storefront Projekt bin ich konkret auf das “Pipes and Filters” Pattern gekommen.
Die Idee (in der Rob Conery Version 
)
Wir haben einen großen Datenhaufen (unser Repository), wo wir über Filter bestimmte Sachen einfach uns abzapfen können, wie wir es brauchen.
Das tolle nun daran: Man kann nicht nur ein Filter nehmen, sondern kann diese auch zusammenschließen um seine Ergebnisse noch weiter einzuengen:
Rob Conery hat dies auch in einem Screencast recht gut erklärt.
Die Umsetzung in .NET mit C# 3.0:
Als “Daten” haben wir in unserem Beispiel einfach eine simple Person Klasse:
public class Person
{
public int Age { get; set; }
public string Name { get; set; }
}
Der Aufbau ist ähnlich empfunden wie bei diesem Blogpost – allerdings etwas vereinfacht (und sollte so nicht verwendet werden (Schnittstellen einbauen!))
Unser DummyPersonRepository hat nur eine Methode, welche statisch ein paar Objekte erzeugt:
public class DummyPersonRepository
{
public IQueryable<Person> GetPersons()
{
List<Person> returnValues = new List<Person>()
{
new Person() { Age = 11, Name = "Bob" },
new Person() { Age = 22, Name = "Alice" },
new Person() { Age = 20, Name = "Robert" },
new Person() { Age = 40, Name = "Hans" },
new Person() { Age = 20, Name = "Peter" },
new Person() { Age = 20, Name = "Oli" },
};
return returnValues.AsQueryable();
}
}
Nun kommen unsere Filter ins Spiel – die nicht direkt ins Repository kommen! Diese werden über “Extension Methods” in einer seperaten Klasse implementiert:
public static class PersonFilters
{
public static IQueryable<Person> WithAge(this IQueryable<Person> qry, int age)
{
return (from x in qry
where x.Age == age
select x);
}
public static IQueryable<Person> NameStartsWith(this IQueryable<Person> qry, string start)
{
return (from x in qry
where x.Name.StartsWith(start)
select x);
}
}
Hier fragen wir einmal nach dem Alter und ob der Name mit was bestimmten beginnt – beides als “Extension Method”.
In unserem Service können wir nun so eine Methode bereitstellen:
public IList<Person> GetPersons(int age, string startsWith)
{
return this.PersonRep.GetPersons().WithAge(age).NameStartsWith(startsWith).ToList();
}
Sehr einfach und effektiv 
Ergebnis:
Am Ende können wir einfach in einer Konsolenapplikation sowas aufrufen:
static void Main(string[] args)
{
PersonService srv = new PersonService();
List<Person> resultList = srv.GetPersons(20, "R").ToList();
foreach (Person result in resultList)
{
Console.WriteLine("Name {0} - Age {1}", result.Name, result.Age);
}
Console.Read();
}
Die Projektstruktur:
Natürlich ist das nur ein simples Beispiel, allerdings konnte ich dies bereits effektiv in einem Projekt einsetzen.
Neben Rob Conerys Storefront kann man sich auch diesen Democode von Mike Bosch anschauen (Teil 1 & 2) – auch er findet diese Idee sehr cool
Insgesamt erlaubt ein solcher Programmierstil deutlich schickeren Code – wie bereits das Wikipedia Beispiel am Anfang gezeigt haben sollte.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Björn Rochel
14. August 2008
Habe mich auch schon mal intensiver mit dem Thema auseinander gesetzt und setze das ganze ebenfalls produktiv ein. Ein bisschen über meine Erfahrungen damit kannst Du hier lesen:
http://bjro.de/2008/08/10/implementing-a-fluent-api-for-the-ribbon/
Ich würde das ganze Thema Fluent API aber nicht auf C# 3.0 reduzieren. Fluent APIs sind auch in C#2.0 gut machbar.
Grüße
Björn
Peter Bucher
25. March 2009
Hoi Robert
Du hast aber leider vergessen zu erwähnen, warum und wie das überhaupt funktioniert
In deinem Fall hast du eine Instanz eines Types (IQueryable), den du als Eingangsparameter für deine Erweiterungsmethoden ansprichst.
Du arbeitest mit dieser Instanz und gibst sie wieder als IQueryable zurück.
Auf der zurückgegebenen Instanz kannst du das wieder machen und es ist immer die gleiche Instanz.
Ohne Erweiterungsmethoden können diese APIs gebaut werden, indem man den this-Zeiger in einer Instanzmethode zurückgibt.
Das wäre der Ursprung vom Fluent-Interface-API-Hype
Robert Mühsig
25. March 2009
Dafür gibt es ja Kommentare
Danke für die Anmerkung und ich hab später auch gemerkt, dass es auch ohne C# 3.0 gegangen wäre