Vor zwei Jahren hat mir ein IT-Leiter aus einem Maschinenbauunternehmen im Schwarzwald sein Intranet gezeigt. Gebaut von einem Entwickler, der mittlerweile woanders arbeitet. Technisch sauber — Custom-CMS auf Basis von Markdown-Dateien und einem selbst gestrickten Parser. "Läuft seit vier Jahren problemlos", sagte er. Ich fragte: "Wer ändert das Template, wenn Marketing eine neue Sektion will?" Drei Sekunden Pause. "Das kriegen wir dann schon irgendwie hin."
Die Wahrheit sah so aus: Ein Freelancer hat sechs Monate später drei Tage gebraucht, um eine neue Kategorie einzubauen — weil der ursprüngliche Code nirgendwo dokumentiert war und die Typen quer durch das Projekt verstreut lagen. 1.800 Euro für drei neue Felder im YAML-Header. Der Geschäftsführer hat mich danach gefragt, ob es "sowas nicht auch fertig zu kaufen gibt".
Khalid Abuhakmeh, Developer Advocate bei JetBrains, zeigt in seinem Artikel eine schlanke Methode, Markdown-Dateien mit YAML-Frontmatter direkt in stark typisierte C#-Objekte zu übersetzen. Das Herzstück ist eine generische MarkdownObject<T>-Klasse, die mit zwei NuGet-Paketen — Markdig und YamlDotNet — auskommt: das Frontmatter landet als typisiertes Datenobjekt, der Markdown-Inhalt als gerendertes HTML. Khalid zeigt das in einem Razor-Pages-Kontext mit Slug-basiertem Routing, inklusive einer defensiven Regex gegen Path-Traversal-Angriffe. Technisch durchdacht, gut erklärt, und für developer-managed Content der richtige Baukasten.
Was davon im KMU wirklich funktioniert
Fangen wir mit dem Guten an: Das Muster ist solide. Wenn ich bei einem Kunden eine .NET-Anwendung mit eingebetteten Inhalten betreue — Produktdatenblätter, Knowledge-Base-Artikel, strukturierte FAQ-Seiten — dann ist genau das der richtige Ansatz. Git-versionierter Content, keine Datenbankabhängigkeit, Zero-Overhead-Deployment. Ich habe das bei einem Softwarehaus mit 60 Mitarbeitenden im Einsatz gesehen: technische Dokumentation, gepflegt von Entwicklern, deployed über die gleiche Pipeline wie der Code. Einmal aufgesetzt, läuft das zwei Jahre ohne Anfassen.
Aber Khalids Artikel schreibt aus einer .NET-zentrischen Entwicklerperspektive. Der Leser ist Entwickler. Der Content-Ersteller ist implizit auch Entwickler — oder zumindest jemand, der komfortabel mit Markdown und YAML-Syntax umgeht. Genau da trennen sich im Mittelstand die Welten.
Ich frage jeden Kunden, bevor wir über Technik reden: Wer schreibt den Inhalt? In 80% der KMU-Projekte, die ich begleitet habe, ist die Antwort nicht der Entwickler, sondern Marketing, Produktmanagement oder der Geschäftsführer persönlich. Die kennen kein YAML. Die wollen kein YAML. Und die werden dir nicht sagen, wenn sie das Datumsfeld falsch formatiert haben — die sagen dir, dass "die Website kaputt ist".
Was im Artikel fehlt: Die drei unbequemen Fragen
Frage 1: Wo leben die Dateien in Production?
Khalid liest Dateien aus einem Data-Verzeichnis per File.ReadAllText. In seiner Demo läuft das lokal. Aber in der Praxis: Sind die .md-Dateien Teil des Deployments? Dann braucht Marketing für jede Textänderung entweder einen Entwickler oder eine CI/CD-Pipeline. Oder liegen sie auf einem Netzlaufwerk? Dann hast du Rechtekonflikte, keine Versionierung und garantiert irgendwann eine korrupte Datei in Production — freitagabends.
Frage 2: Caching.
Der Code liest bei jedem Request von der Festplatte. Für ein Demo: perfekt. Für eine Seite mit 500 Seitenaufrufen am Tag: noch vertretbar. Für alles darüber: IMemoryCache einbauen, oder den Dateiinhalt beim Startup laden. Das ist keine Kritik am Artikel — Khalid sagt selbst, es ist ein "quick experiment" — aber im KMU-Kontext vergisst man das gerne und wundert sich dann über I/O-Last auf dem Server.
Frage 3: Schema-Evolution.
Was passiert, wenn du in sechs Monaten ein neues Pflichtfeld in dein Asset-Objekt einfügst? Alle bestehenden Markdown-Dateien haben dieses Feld nicht. YamlDotNet deserialisiert auf den C#-Default-Wert — leerer String oder null. Kein Fehler, kein Log-Eintrag. Stiller Datenverlust. Ich hatte einen Kunden, der sechs Monate lang null-Autoren in seiner Knowledge Base hatte, weil das Schema-Update die alten Dateien nicht erwischt hat. Erst beim SEO-Audit ist das aufgefallen.
Meine konkrete Empfehlung
Für wen dieser Ansatz richtig ist:
Du hast ein .NET-Team, das Content auch pflegt. Die Inhalte sind entwicklernah — technische Docs, Release Notes, strukturierte interne Artikel. Du willst Git-Versionierung für Inhalte und kein weiteres System. Dann: Ja, dieses Muster lohnt sich. Khalids MarkdownObject<T> ist eine saubere Abstraktion, die ich genauso bauen würde.
Für wen nicht:
Marketing schreibt die Inhalte. Oder: Du hast einen Entwickler, der das baut, und niemanden, der es danach wartet. Oder: Dein Inhalt ändert sich häufig und du willst kein Deployment für jede Textänderung rollen. Das trifft auf die Mehrzahl der KMU-Projekte zu, die ich sehe — und dort wäre ich mit Umbraco für .NET-Puristen oder Directus als API-first-Option langfristig besser aufgestellt.
Die goldene Mitte, die ich in zwei aktuellen Mandaten einsetze: Content in Git, aber mit einem Schema-Validator als Pre-Commit-Hook. Jede Markdown-Datei wird gegen ein JSON-Schema validiert, bevor sie in die Pipeline kommt. Marketing schreibt nie direkt ins Repo — sondern über ein kleines internes Web-Interface, das nur valide Dateien committet. Das kombiniert die Eleganz von Khalids Ansatz mit einer Guardrail, die im Alltag tatsächlich hält.
Khalids Artikel ist ein guter technischer Baustein — aber ein Baustein in einem Fundament, das erst dann trägt, wenn du die organisatorische Frage beantwortet hast: Wer besitzt diesen Content in drei Jahren, und was kostet eine Schemaänderung dann?
Der vollständige Original-Beitrag von Khalid Abuhakmeh: Strongly-Typed Markdown for ASP.NET Core Content Apps
Wenn du gerade vor einer ähnlichen Entscheidung stehst — Custom-CMS bauen oder kaufen, .NET-Eigenentwicklung oder Standardprodukt — dann lass uns das in 30 Minuten durchdenken. Kein Pitch, keine Folien, nur Klartext.
— Bernhard