{"id":216,"date":"2026-05-09T11:42:10","date_gmt":"2026-05-09T11:42:10","guid":{"rendered":"https:\/\/www.fabricioruch.ch\/?p=216"},"modified":"2026-05-09T11:42:10","modified_gmt":"2026-05-09T11:42:10","slug":"decoupling-in-wpf-using-messagebox-as-example","status":"publish","type":"post","link":"https:\/\/www.fabricioruch.ch\/?p=216","title":{"rendered":"Decoupling in WPF Using MessageBox as Example"},"content":{"rendered":"\n

A Deep-Dive with Real Chrona Code Examples<\/h2>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Many WPF applications begin with direct MessageBox.Show(...)<\/code> calls.<\/p>\n\n\n\n

At first, this feels completely reasonable. A save confirmation here, an error dialog there, a warning before deletion. The implementation is fast, obvious, and immediately functional.<\/p>\n\n\n\n

As the application grows, however, this becomes an architectural problem.<\/p>\n\n\n\n

Once MessageBox.Show(...)<\/code> is scattered across ViewModels, services, and workflow logic, UI behavior becomes tightly coupled to application behavior. Every feature decides independently how dialogs should work. Every ViewModel depends directly on WPF dialog primitives. Every future redesign requires widespread refactoring.<\/p>\n\n\n\n

Chrona takes a different approach.<\/p>\n\n\n\n

Instead of coupling feature code directly to WPF dialogs, the application routes all dialog interaction through a layered abstraction:<\/p>\n\n\n\n

Feature Code\n    \u2193\nIDialogService\n    \u2193\nIMessageDialogHost\n    \u2193\nCustomDialogHost\n    \u2193\nCustomMessageDialogWindow\n<\/code><\/pre>\n\n\n\n
This separation is architecturally strong because the business and workflow layers no longer depend on concrete UI rendering details.<\/p>\n\n\n\n
The result is a dialog system that is:<\/p>\n\n\n\n
    \n
  • replaceable<\/li>\n\n\n\n
  • testable<\/li>\n\n\n\n
  • design-consistent<\/li>\n\n\n\n
  • future-proof<\/li>\n\n\n\n
  • independent from direct WPF primitives<\/li>\n<\/ul>\n\n\n\n
    That matters far more in production systems than most MVVM tutorials acknowledge.<\/p>\n\n\n\n
    \n\n\n\n
    The Real Problem with MessageBox.Show<\/h1>\n\n\n\n
    A direct message box call looks harmless:<\/p>\n\n\n\n
    MessageBox.Show(\n    \"Entry saved successfully.\",\n    \"Information\",\n    MessageBoxButton.OK,\n    MessageBoxImage.Information);\n<\/code><\/pre>\n\n\n\n
    The problem is not the individual call.<\/p>\n\n\n\n
    The problem is architectural spread.<\/p>\n\n\n\n
    Once dozens or hundreds of these calls exist across a desktop application, several issues emerge:<\/p>\n\n\n\n
    ViewModels become tied to WPF types.\nDialog design becomes inconsistent.\nTesting becomes harder.\nModal behavior becomes fragmented.\nFuture redesigns require mass refactoring.<\/code><\/pre>\n\n\n\n
    Even worse, the application logic starts speaking in framework-specific terminology.<\/p>\n\n\n\n
    A ViewModel should not need to know what MessageBoxButton.YesNoCancel<\/code> means. The ViewModel should only express intent:<\/p>\n\n\n\n
    I need a confirmation.\nI need to show an error.\nI need to notify the user.<\/code><\/pre>\n\n\n\n
    How that intent is rendered visually should be infrastructure behavior.<\/p>\n\n\n\n
    Chrona separates exactly these concerns.<\/p>\n\n\n\n
    \n\n\n\n
    Replacing WPF Types with Application Semantics<\/h1>\n\n\n\n
    The first important architectural step in Chrona is removing WPF dialog types from the application-facing API.<\/p>\n\n\n\n
    Instead of exposing MessageBoxButton<\/code>, MessageBoxImage<\/code>, or MessageBoxResult<\/code>, the application defines its own dialog semantics.<\/p>\n\n\n\n
    namespace Chrona.Services.App.Interfaces;\n\npublic enum DialogButtons\n{\n    Ok,\n    OkCancel,\n    YesNo,\n    YesNoCancel\n}<\/code><\/pre>\n\n\n\n
    namespace Chrona.Services.App.Interfaces;\n\npublic enum DialogIcon\n{\n    None,\n    Information,\n    Warning,\n    Error,\n    Question\n}<\/code><\/pre>\n\n\n\n
    namespace Chrona.Services.App.Interfaces;\n\npublic enum DialogResult\n{\n    None,\n    Ok,\n    Cancel,\n    Yes,\n    No\n}<\/code><\/pre>\n\n\n\n
    This is an extremely important architectural move.<\/p>\n\n\n\n
    The ViewModel and service layers now speak in application language instead of WPF language.<\/p>\n\n\n\n
    That creates major long-term flexibility.<\/p>\n\n\n\n
    The application no longer depends on:<\/p>\n\n\n\n
    MessageBoxButton\nMessageBoxImage\nMessageBoxResult<\/code><\/pre>\n\n\n\n
    which means the UI framework can evolve independently from the application workflows.<\/p>\n\n\n\n
    This may sound subtle, but it is one of the strongest decoupling decisions in the entire dialog architecture.<\/p>\n\n\n\n
    \n\n\n\n
    High-Level Feature API Through IDialogService<\/h1>\n\n\n\n
    The feature-facing API remains intentionally high-level and workflow-oriented.<\/p>\n\n\n\n
    namespace Chrona.Services.App.Interfaces;\n\npublic interface IDialogService\n{\n    DialogResult ShowDialog(\n        string message,\n        string title,\n        DialogButtons buttons = DialogButtons.Ok,\n        DialogIcon icon = DialogIcon.Information);\n\n    Task<DialogResult> ShowDialogAsync(\n        string message,\n        string title,\n        DialogButtons buttons = DialogButtons.Ok,\n        DialogIcon icon = DialogIcon.Information);\n\n    bool Confirm(\n        string message,\n        string title,\n        DialogIcon icon = DialogIcon.Question);\n\n    string? ShowOpenFileDialog(\n        string filter,\n        string title);\n\n    string? ShowSaveFileDialog(\n        string filter,\n        string defaultFileName);\n\n    \/\/ Toast notifications\n    void ShowToast(string message, DialogIcon icon);\n\n    void ShowSuccess(\n        string message,\n        IReadOnlyList<ToastActionOption>? actions = null);\n}\n<\/code><\/pre>\n\n\n\n
    This is good service design because the call sites remain readable and intention-driven.<\/p>\n\n\n\n
    Feature code does not need to know:<\/p>\n\n\n\n
      \n
    • whether the dialog is modal<\/li>\n\n\n\n
    • whether a custom overlay is used<\/li>\n\n\n\n
    • whether a native WPF window is used<\/li>\n\n\n\n
    • whether notifications appear as toasts<\/li>\n\n\n\n
    • whether dialogs are queued internally<\/li>\n<\/ul>\n\n\n\n
      The ViewModel simply expresses intent.<\/p>\n\n\n\n
      That keeps workflow logic clean.<\/p>\n\n\n\n
      \n\n\n\n
      IMessageDialogHost: The Critical Architectural Boundary<\/h1>\n\n\n\n
      The actual decoupling point is IMessageDialogHost<\/code>.<\/p>\n\n\n\n
      namespace Chrona.Services.App.Interfaces;\n\npublic interface IMessageDialogHost\n{\n    DialogResult ShowDialog(\n        string message,\n        string title,\n        DialogButtons buttons,\n        DialogIcon icon);\n}\n<\/code><\/pre>\n\n\n\n
      This interface is the true boundary between:<\/p>\n\n\n\n
      application interaction policy<\/code><\/pre>\n\n\n\n
      and:<\/p>\n\n\n\n
      concrete UI rendering<\/code><\/pre>\n\n\n\n
      Everything above this interface remains stable.<\/p>\n\n\n\n
      Everything below it becomes replaceable.<\/p>\n\n\n\n
      That separation gives the architecture significant flexibility.<\/p>\n\n\n\n
      The application can later replace:<\/p>\n\n\n\n
        \n
      • native WPF windows<\/li>\n\n\n\n
      • MahApps dialogs<\/li>\n\n\n\n
      • Fluent overlays<\/li>\n\n\n\n
      • custom modal systems<\/li>\n\n\n\n
      • accessibility-enhanced dialogs<\/li>\n\n\n\n
      • web-style popup layers<\/li>\n<\/ul>\n\n\n\n
        without rewriting feature logic.<\/p>\n\n\n\n
        That is exactly what good desktop architecture should enable.<\/p>\n\n\n\n
        \n\n\n\n
        DialogService as a Policy Layer<\/h1>\n\n\n\n
        Chrona\u2019s DialogService<\/code> does not render dialogs directly.<\/p>\n\n\n\n
        Instead, it acts as an interaction-policy layer.<\/p>\n\n\n\n
        public class DialogService : IDialogService\n{\n    private readonly IMessageDialogHost _messageDialogHost;\n    private readonly IToastService _toastService;\n\n    public DialogService(\n        IToastService toastService,\n        IMessageDialogHost messageDialogHost)\n    {\n        _toastService = toastService;\n        _messageDialogHost = messageDialogHost;\n    }\n\n    public DialogResult ShowDialog(\n        string message,\n        string title,\n        DialogButtons buttons = DialogButtons.Ok,\n        DialogIcon icon = DialogIcon.Information)\n    {\n        \/\/ Yes\/No questions remain modal\n        if (buttons == DialogButtons.YesNo ||\n            buttons == DialogButtons.YesNoCancel)\n        {\n            return _messageDialogHost.ShowDialog(\n                message,\n                title,\n                buttons,\n                icon);\n        }\n\n        \/\/ Simple informational messages use toasts\n        ShowToast(message, icon);\n\n        return DialogResult.Ok;\n    }\n}<\/code><\/pre>\n\n\n\n
        This is a very strong pattern.<\/p>\n\n\n\n
        The service owns interaction policy:<\/p>\n\n\n\n
        When should interaction be modal?\nWhen should interaction be non-blocking?<\/code><\/pre>\n\n\n\n
        But it does not own rendering.<\/p>\n\n\n\n
        Rendering belongs to the dialog host.<\/p>\n\n\n\n
        That separation keeps responsibilities extremely clean.<\/p>\n\n\n\n
        \n\n\n\n
        Modal vs Non-Modal UX Policy<\/h1>\n\n\n\n
        Chrona distinguishes between two fundamentally different interaction categories.<\/p>\n\n\n\n
        Decision workflows remain modal:<\/p>\n\n\n\n
        Yes\/No\nYes\/No\/Cancel<\/code><\/pre>\n\n\n\n
        because the user must explicitly decide something before continuing.<\/p>\n\n\n\n
        Informational messages become non-blocking toast notifications:<\/p>\n\n\n\n
        Save successful\nExport completed\nOperation finished<\/code><\/pre>\n\n\n\n
        This dramatically improves UX quality.<\/p>\n\n\n\n
        Users are interrupted only when interruption is actually necessary.<\/p>\n\n\n\n
        Many desktop applications overuse modal dialogs and unintentionally create interaction fatigue.<\/p>\n\n\n\n
        Chrona avoids that by centralizing interaction policy.<\/p>\n\n\n\n
        \n\n\n\n
        CustomDialogHost: UI Rendering Infrastructure<\/h1>\n\n\n\n
        The actual UI rendering happens inside CustomDialogHost<\/code>.<\/p>\n\n\n\n
        public class CustomDialogHost : IMessageDialogHost\n{\n    public DialogResult ShowDialog(\n        string message,\n        string title,\n        DialogButtons buttons,\n        DialogIcon icon)\n    {\n        if (Application.Current?.Dispatcher is not null &&\n            !Application.Current.Dispatcher.CheckAccess())\n        {\n            return Application.Current.Dispatcher.Invoke(\n                () => ShowDialogCore(\n                    message,\n                    title,\n                    buttons,\n                    icon));\n        }\n\n        return ShowDialogCore(\n            message,\n            title,\n            buttons,\n            icon);\n    }\n\n    private static DialogResult ShowDialogCore(\n        string message,\n        string title,\n        DialogButtons buttons,\n        DialogIcon icon)\n    {\n        var dialog =\n            new CustomMessageDialogWindow(\n                title,\n                message,\n                buttons,\n                icon);\n\n        if (Application.Current?.MainWindow is\n            { IsLoaded: true } mainWindow &&\n            mainWindow.IsVisible)\n        {\n            dialog.Owner = mainWindow;\n        }\n\n        dialog.ShowDialog();\n\n        return dialog.DialogOutcome;\n    }\n}\n<\/code><\/pre>\n\n\n\n
        Several strong implementation details are visible here.<\/p>\n\n\n\n
        The host handles UI-thread marshaling automatically.<\/p>\n\n\n\n
        The host assigns dialog ownership to the main window.<\/p>\n\n\n\n
        The host returns application-level DialogResult<\/code> values rather than WPF-native types.<\/p>\n\n\n\n
        The host isolates all rendering-specific behavior from application workflows.<\/p>\n\n\n\n
        This is infrastructure code in the best sense: centralized, replaceable, and invisible to feature logic.<\/p>\n\n\n\n
        \n\n\n\n
        Building a Dialog That Feels Native to the App<\/h1>\n\n\n\n
        Chrona\u2019s custom dialog window is fully integrated into the application design system.<\/p>\n\n\n\n
        The dialog uses existing dynamic resources:<\/p>\n\n\n\n
        SurfaceBrush\nDividerBrush\nPrimaryBrush\nPrimaryLightBrush<\/code><\/pre>\n\n\n\n
        which makes the dialog visually consistent with the rest of the application.<\/p>\n\n\n\n
        The shell itself is highly customized:<\/p>\n\n\n\n
        <Window\n    WindowStartupLocation=\"CenterOwner\"\n    ResizeMode=\"NoResize\"\n    WindowStyle=\"None\"\n    ShowInTaskbar=\"False\"\n    Background=\"Transparent\"\n    AllowsTransparency=\"True\"\n    SizeToContent=\"WidthAndHeight\"\n    MinWidth=\"460\"\n    MaxWidth=\"680\"><\/code><\/pre>\n\n\n\n
        This is important because native MessageBox<\/code> windows often break visual consistency in modern WPF applications.<\/p>\n\n\n\n
        Custom dialogs allow:<\/p>\n\n\n\n
          \n
        • branded UX<\/li>\n\n\n\n
        • theme consistency<\/li>\n\n\n\n
        • dark mode support<\/li>\n\n\n\n
        • consistent typography<\/li>\n\n\n\n
        • accessibility improvements<\/li>\n\n\n\n
        • animation support<\/li>\n\n\n\n
        • richer layouts<\/li>\n<\/ul>\n\n\n\n
          without changing feature logic.<\/p>\n\n\n\n
          \n\n\n\n
          Visual Structure and Theming<\/h1>\n\n\n\n
          The dialog uses application-level brushes and effects:<\/p>\n\n\n\n
          <Border\n    Background=\"{DynamicResource SurfaceBrush}\"\n    BorderBrush=\"{DynamicResource DividerBrush}\"\n    BorderThickness=\"1\"\n    CornerRadius=\"12\"><\/code><\/pre>\n\n\n\n
          along with a shadow effect:<\/p>\n\n\n\n
          <DropShadowEffect\n    BlurRadius=\"24\"\n    ShadowDepth=\"4\"\n    Opacity=\"0.22\"\n    Color=\"Black\" \/><\/code><\/pre>\n\n\n\n
          The header includes an icon badge and title region:<\/p>\n\n\n\n
          <Border\n    Background=\"{DynamicResource BackgroundBrush}\"\n    BorderBrush=\"{DynamicResource DividerBrush}\"\n    BorderThickness=\"0,0,0,1\"><\/code><\/pre>\n\n\n\n
          while the footer uses application button styles:<\/p>\n\n\n\n
          <Button\n    Style=\"{DynamicResource SecondaryButtonStyle}\" \/>\n\n<Button\n    Style=\"{DynamicResource PrimaryButtonStyle}\" \/>\n<\/code><\/pre>\n\n\n\n
          This creates a dialog experience that feels like a natural extension of the application rather than an external operating-system popup.<\/p>\n\n\n\n
          \n\n\n\n
          Mapping Application Semantics to UX<\/h1>\n\n\n\n
          The code-behind translates dialog semantics into actual visuals.<\/p>\n\n\n\n
          Icon configuration is centralized:<\/p>\n\n\n\n
          private void ConfigureIcon(DialogIcon icon)\n{\n    var (kind, badgeKey, iconKey) = icon switch\n    {\n        DialogIcon.Error =>\n            (PackIconMaterialKind.AlertCircle,\n             \"ErrorBrush\",\n             \"OnPrimaryTextBrush\"),\n\n        DialogIcon.Warning =>\n            (PackIconMaterialKind.AlertOutline,\n             \"WarningBrush\",\n             \"OnPrimaryTextBrush\"),\n\n        DialogIcon.Question =>\n            (PackIconMaterialKind.HelpCircleOutline,\n             \"PrimaryLightBrush\",\n             \"PrimaryBrush\"),\n\n        DialogIcon.Information =>\n            (PackIconMaterialKind.InformationOutline,\n             \"PrimaryLightBrush\",\n             \"PrimaryBrush\"),\n\n        _ =>\n            (PackIconMaterialKind.InformationOutline,\n             \"PrimaryLightBrush\",\n             \"PrimaryBrush\")\n    };\n\n    IconGlyph.Kind = kind;\n\n    IconBadge.Background =\n        ResolveBrush(badgeKey, Brushes.LightGray);\n\n    IconGlyph.Foreground =\n        ResolveBrush(iconKey, Brushes.DodgerBlue);\n}\n<\/code><\/pre>\n\n\n\n
          The dialog window does not expose raw icon implementation details to the application layer. It simply maps semantic intent:<\/p>\n\n\n\n
          Error\nWarning\nInformation\nQuestion<\/code><\/pre>\n\n\n\n
          into actual UI styling.<\/p>\n\n\n\n
          That keeps the application semantics stable while allowing the visual implementation to evolve independently.<\/p>\n\n\n\n
          \n\n\n\n
          Button Configuration and Localization<\/h1>\n\n\n\n
          Button configuration follows the same pattern.<\/p>\n\n\n\n
          private void ConfigureButtons(DialogButtons buttons)\n{\n    SecondaryButton.Visibility = Visibility.Collapsed;\n    TertiaryButton.Visibility = Visibility.Collapsed;\n\n    switch (buttons)\n    {\n        case DialogButtons.Ok:\n            PrimaryButton.Content = \"OK\";\n            PrimaryButton.IsDefault = true;\n            SecondaryButton.IsCancel = false;\n            break;\n\n        case DialogButtons.YesNo:\n            PrimaryButton.Content = \"Ja\";\n            SecondaryButton.Content = \"Nein\";\n            SecondaryButton.Visibility = Visibility.Visible;\n            PrimaryButton.IsDefault = true;\n            SecondaryButton.IsCancel = true;\n            break;\n    }\n}<\/code><\/pre>\n\n\n\n
          This is important because localization and UX policy remain centralized.<\/p>\n\n\n\n
          If button wording changes later, the application does not need to update dozens of dialog call sites.<\/p>\n\n\n\n
          \n\n\n\n
          Dialog Outcome Mapping<\/h1>\n\n\n\n
          The button click handlers map visual actions back into application semantics:<\/p>\n\n\n\n
          private void PrimaryButton_Click(\n    object sender,\n    RoutedEventArgs e)\n{\n    DialogOutcome =\n        PrimaryButton.Content?.ToString() switch\n        {\n            \"Ja\" => AppDialogResult.Yes,\n            _ => AppDialogResult.Ok\n        };\n\n    DialogResult = true;\n\n    Close();\n}<\/code><\/pre>\n\n\n\n
          and:<\/p>\n\n\n\n
          private void SecondaryButton_Click(\n    object sender,\n    RoutedEventArgs e)\n{\n    DialogOutcome =\n        SecondaryButton.Content?.ToString() switch\n        {\n            \"Nein\" => AppDialogResult.No,\n            _ => AppDialogResult.Cancel\n        };\n}<\/code><\/pre>\n\n\n\n
          Again, the application layer never sees WPF-native dialog primitives.<\/p>\n\n\n\n
          Everything flows through application-defined semantics.<\/p>\n\n\n\n
          \n\n\n\n
          One DI Registration Changes the Entire Application<\/h1>\n\n\n\n
          The actual dialog-system swap happens in one place:<\/p>\n\n\n\n
          services.AddSingleton<IMessageDialogHost, CustomDialogHost>();\n\nservices.AddSingleton<IDialogService, DialogService>();<\/code><\/pre>\n\n\n\n
          Previously, this could have pointed to a different implementation:<\/p>\n\n\n\n
          WpfMessageDialogHost<\/code><\/pre>\n\n\n\n
          Now it points to:<\/p>\n\n\n\n
          CustomDialogHost<\/code><\/pre>\n\n\n\n
          Every call site remains unchanged.<\/p>\n\n\n\n
          That is the real value of the abstraction.<\/p>\n\n\n\n
          \n\n\n\n
          Global Error Handling Also Benefits<\/h1>\n\n\n\n
          Chrona even routes exception handling through the same host abstraction.<\/p>\n\n\n\n
          public class ExceptionHandler\n{\n    private readonly IMessageDialogHost _messageDialogHost;\n\n    private readonly ILogger<ExceptionHandler>? _logger;\n\n    public ExceptionHandler(\n        IMessageDialogHost messageDialogHost,\n        ILogger<ExceptionHandler>? logger = null)\n    {\n        _messageDialogHost = messageDialogHost;\n        _logger = logger;\n    }\n}<\/code><\/pre>\n\n\n\n
          The safe wrapper is particularly strong:<\/p>\n\n\n\n
          private DialogResult SafeShowDialog(\n    string message,\n    string title,\n    DialogButtons buttons,\n    DialogIcon icon)\n{\n    try\n    {\n        return _messageDialogHost.ShowDialog(\n            message,\n            title,\n            buttons,\n            icon);\n    }\n    catch\n    {\n        \/\/ Fallback if UI is unavailable\n        return DialogResult.None;\n    }\n}<\/code><\/pre>\n\n\n\n
          Even critical error dialogs remain inside the same architectural system.<\/p>\n\n\n\n
          That creates consistency across the entire application.<\/p>\n\n\n\n
          \n\n\n\n
          Why This Architecture Is Valuable in Real Projects<\/h1>\n\n\n\n
          This dialog architecture provides several long-term advantages.<\/p>\n\n\n\n
          Design consistency improves because all dialogs follow the same visual system.<\/p>\n\n\n\n
          Replaceability improves because rendering can evolve independently from workflows.<\/p>\n\n\n\n
          Maintainability improves because ViewModels remain free of WPF-specific dialog details.<\/p>\n\n\n\n
          Scalability improves because richer dialog types can be added cleanly:<\/p>\n\n\n\n
          detail sections\ndanger-style confirmations\ncheckbox confirmations\nstacktrace expansions\nmulti-action dialogs<\/code><\/pre>\n\n\n\n
          Testability improves because both IDialogService<\/code> and IMessageDialogHost<\/code> can be mocked or faked during tests.<\/p>\n\n\n\n
          Most importantly, the application now owns its dialog semantics instead of delegating them to framework primitives.<\/p>\n\n\n\n
          That is a major architectural improvement.<\/p>\n\n\n\n
          \n\n\n\n
          Possible Future Enhancements<\/h1>\n\n\n\n
          Chrona\u2019s architecture already provides a strong foundation, but several natural extensions would fit cleanly into the current design.<\/p>\n\n\n\n
          A DialogSeverity<\/code> abstraction could support specialized destructive-action styling.<\/p>\n\n\n\n
          Technical-detail sections could display stack traces or expandable error diagnostics.<\/p>\n\n\n\n
          Animations such as fade or scale transitions could improve perceived UX quality.<\/p>\n\n\n\n
          An async dialog-host API could support queued or non-modal workflows later.<\/p>\n\n\n\n
          Visual regression screenshots could ensure dialog consistency across releases.<\/p>\n\n\n\n
          The important point is that the architecture already supports these future evolutions cleanly because rendering and workflow semantics are separated properly.<\/p>\n","protected":false},"excerpt":{"rendered":"
          A Deep-Dive with Real Chrona Code Examples Many WPF applications begin with direct MessageBox.Show(…) calls. At first, this feels completely reasonable. A save confirmation here, an error dialog there, a warning before deletion. The implementation is fast, obvious, and immediately functional. As the application grows, however, this becomes an architectural problem. Once MessageBox.Show(…) is scattered […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,27,8,25,34],"tags":[],"class_list":["post-216","post","type-post","status-publish","format-standard","hentry","category-csharp","category-programming-principles","category-software-architecture","category-software-engineering","category-wpf"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=216"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/216\/revisions"}],"predecessor-version":[{"id":218,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/216\/revisions\/218"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}