„Dann bekommen Sie eine Hausaufgabe, damit der Kunde sieht, wie sie programmieren können“, kündigte der Recruiter schon vor dem Vorstellungsgespräch an. Sie würden das immer so machen, meinte auch der Interviewpartner. Ich war gespannt, was denn da käme.
Was dann kam, hat mich vollkommen umgehauen:
/// <summary>
/// function to return the place in the magazine level
/// </summary>
///
/// <param name="places"> Array of bools for dimension n. true means available position, false not available (occupied) </param>
/// <param name="isRotary"> Flag, whether the level is rotary (last position is neigbour of first ) </param>
/// <param name="neededPlaces"> Number of places needed </param>
/// <returns> Index of first position found ( zero based ) or -1 if nothing found </returns>
static public int FindFreePlace(bool[] places, bool isRotary, int neededPlaces)
{
// Insert the code
}
Es hätte einfach sein können
Das Hallo-Welt Beispiel fiddle für MVC war die Grundlage. Dort wurde eine Frage vom UI an den Server geschickt. Dieser antwortet mit einer zufälligen Zeichenfolge. Bei der Aufgabe sollte ich im UI drei Parameter schicken und im Server ein Ergebnis berechnen und zurückschicken.
Ich kopierte die Zeilen zu der Frage zweimal und benannte die Deklarationen um. Das garantierte ein erstes Erfolgserlebnis.
Erfreut implementierte ich die Places als Zeichenfolge von TFs, damit waren der Places Parameter fertig. Eine Checkbox stellte IsRotary dar und eine Zeichenfolge mit Prüfung auf Zahlwert stellte NeededPlaces dar.
Da war ich doch schon nahezu fertig, nicht wahr?
Es fehlte nur noch die Übertragung zum Server. Ich erweiterte die Zahl Parameter auf der Seite des Controllers.
Ein anschließende Run zeigte: Es fehlte die Übertragung zum Server. Ich nahm alles wieder zurück und spiegelte die Frage.
Das Hallo Welt Beispiel übertrug die Frage nie richtig an den Server. Dort wurde nur ein zufälliger String zurückgegeben.
Verdammt, wie geht das mit der Übertragung zum Server?
Ich schaute mir das Netzprotokoll an. Die Parameter waren da. Das konnte ich per JSON und auch per Url Kodierung machen. Es war egal. Am Server kam nichts an.
Ich hätte an dieser Stelle ein „when in doubt, run in circles, scream and shout“ eingelegen können, entschied mich aber zunächst einen Kaffee trinken und danach das Internet durchsuchen.
Ich entdeckte einen Hinweis. Dieser beschrieb die [FromBody] Anmerkung. Diese instruiert den Mapper, den Parameter einfach in der angegeben Form weiterzugeben. War das die einfache Antwort?
Der Compiler kannte FromBody nicht. Er wollte Assemblies haben. Die, die ich angab, fand der Compiler, aber FromBody war da nicht drin. Vermutlich war die dotnetfiddle Version 4.5 neuer, als die 2013 beschriebene Version.
Mainstream — Microsoft will immer Mainstream
Mit einem weiteren Kaffee las ich den Artikel noch einmal neu. Dort stand, dass „komplexes einfach geht“. Ein C# Mapper bildet das aufeinander ab. Nur wenn man etwas Besonderes machte, bräuchte man einen Trick.
Was war die Mainstream Anwendung von Html Formulare?
Im Normalfall werden die Daten in einer Struktur an den Server geschickt, dieser wertet so etwas aus und gibt ein html zurück. Solch ein Fiddle konnte ich finden.
Ein Groschen fiel und dann stimmten Model und View.
Die Freispeicherverwaltung war damit trivial.
Geht das nicht besser?
Mit diesem Model View Controller Paradigma von Microsoft kann ich Webseiten bauen, die ein Formular anzeigen und zum Ausfüllen anbieten. Damit wird der traditionelle PC aufgespalten in C#-Serveranteil, der Model und Controller realisiert, und in Html, das auf den unterschiedlichsten Geräten angezeigt und bearbeitet wird.
Das ist zwar schon einiges, aber passt nicht zu den Möglichkeiten, die per Html verfügbar sind. Auf einer Webseite kann wesentlich mehr geprüft und verarbeitet werden, als noch vor einigen Jahren möglich war.
Dazu werde ich demnächst mehr erzählen.