Merge pull request #5980 from MicrosoftDocs/main

Auto Publish – main to live - 2025-11-11 21:18 UTC

Author: learn-build-service-prod[bot]

hub/apps/develop/data-binding/bind-to-hierarchical-data-and-create-a-master-details-view.md

@@ -1,37 +1,38 @@
 ---
 ms.assetid: 6c563dd4-3dd0-4175-a1ab-7a1103fc9559
-title: Bind hierarchical data and create a master/details view with Windows App SDK
-description: You can make a multi-level master/details (also known as list-details) view of hierarchical data by binding items controls to CollectionViewSource instances that are bound together in a chain.
-ms.date: 12/13/2022
+title: Bind hierarchical data and create a master/details view with WinUI
+description: Create a multi-level master/details view of hierarchical data in WinUI by binding items controls to CollectionViewSource instances. Learn how to implement this structure.
+ms.date: 11/11/2025
 ms.topic: how-to
 keywords: windows 10, windows 11, winui, windows app sdk, windows ui, xBind
 ms.localizationpriority: medium
+# customer intent: As a Windows developer, I want to learn how to bind hierarchical data and create a master/details view with WinUI.
 ---
 
-# Bind hierarchical data and create a master/details view with Windows App SDK
+# Bind hierarchical data and create a master/details view with WinUI
 
-> [!NOTE]
-> Also see the [Master/detail UWP sample](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/XamlMasterDetail).
+Learn how to create a multilevel master/details view of hierarchical data in WinUI by binding items controls to [CollectionViewSource](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances. This article explains how to use the [{x:Bind} markup extension](/windows/apps/develop/platform/xaml/x-bind-markup-extension) for better performance and the [{Binding} markup extension](/windows/apps/develop/platform/xaml/binding-markup-extension) when flexibility is needed.
 
-You can make a multi-level master/details (also known as list-details) view of hierarchical data by binding items controls to [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances that are bound together in a chain. In this topic we use the [{x:Bind} markup extension](/windows/apps/develop/platform/xaml/x-bind-markup-extension) where possible, and the more flexible (but less performant) [{Binding} markup extension](/windows/apps/develop/platform/xaml/binding-markup-extension) where necessary.
+One common structure for WinUI apps is to navigate to different details pages when a user makes a selection in a master list. This structure is useful when you want to provide a rich visual representation of each item at every level in a hierarchy. Another option is to display multiple levels of data on a single page. This structure is useful when you want to display a few simple lists that let the user quickly drill down to an item of interest. This article describes how to implement this interaction. The [CollectionViewSource](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances keep track of the current selection at each hierarchical level.
 
-One common structure for Windows App SDK apps is to navigate to different details pages when a user makes a selection in a master list. This is useful when you want to provide a rich visual representation of each item at every level in a hierarchy. Another option is to display multiple levels of data on a single page. This is useful when you want to display a few simple lists that let the user quickly drill down to an item of interest. This topic describes how to implement this interaction. The [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances keep track of the current selection at each hierarchical level.
+You create a view of a sports team hierarchy that's organized into lists for leagues, divisions, and teams, and includes a team details view. When you select an item from any list, the subsequent views update automatically.
 
-We'll create a view of a sports team hierarchy that is organized into lists for leagues, divisions, and teams, and includes a team details view. When you select an item from any list, the subsequent views update automatically.
+:::image type="content" source="images/xaml-masterdetails.png" alt-text="Screenshot of a master/details view of a sports hierarchy. The view includes leagues, divisions, and teams.":::
 
-![master/details view of a sports hierarchy](images/xaml-masterdetails.png)
+> [!TIP]
+> Also see the [Master/detail UWP sample](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/XamlMasterDetail).
 
 ## Prerequisites
 
-This topic assumes that you know how to create a basic Windows App SDK app. For instructions on creating your first Windows App SDK app, see [Create your first WinUI 3 (Windows App SDK) project](/windows/apps/winui/winui3/create-your-first-winui3-app).
+This article assumes that you know how to create a basic WinUI app. For instructions on creating your first WinUI app, see [Create a WinUI app](/windows/apps/tutorials/winui-notes/intro).
 
 ## Create the project
 
 Create a new **Blank App, Packaged (WinUI 3 in Desktop)** project. Name it "MasterDetailsBinding".
 
 ## Create the data model
 
-Add a new class to your project, name it **ViewModel.cs**, and add this code to it. This will be your binding source class.
+Add a new class to your project, name it **ViewModel.cs**, and add this code to it. This class is your binding source class.
 
 ```cs
 using System.Collections.Generic;
@@ -101,7 +102,7 @@ namespace MasterDetailsBinding
 
 ## Create the view
 
-Next, expose the binding source class from the class that represents your page of markup. We do that by adding a property of type `LeagueList` to **MainWindow**.
+Next, expose the binding source class from the class that represents your page of markup. Add a property of type `LeagueList` to **MainWindow**.
 
 ```cs
 namespace MasterDetailsBinding
@@ -118,7 +119,7 @@ namespace MasterDetailsBinding
 }
 ```
 
-Finally, replace the contents of the **MainWindow.xaml** file with the following markup, which declares three [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances and binds them together in a chain. The subsequent controls can then bind to the appropriate `CollectionViewSource`, depending on its level in the hierarchy.
+Finally, replace the contents of the **MainWindow.xaml** file with the following markup. This markup declares three [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource) instances and binds them together in a chain. The subsequent controls can then bind to the appropriate `CollectionViewSource`, depending on its level in the hierarchy.
 
 ``` xaml
 <Window
@@ -198,7 +199,7 @@ Finally, replace the contents of the **MainWindow.xaml** file with the following
 </Window>
 ```
 
-Note that by binding directly to the [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource), you're implying that you want to bind to the current item in bindings where the path cannot be found on the collection itself. There's no need to specify the `CurrentItem` property as the path for the binding, although you can do that if there's any ambiguity. For example, the [**ContentControl**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.contentcontrol) representing the team view has its [**Content**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.contentcontrol.content) property bound to the `Teams` `CollectionViewSource`. However, the controls in the [**DataTemplate**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.datatemplate) bind to properties of the `Team` class because the `CollectionViewSource` automatically supplies the currently selected team from the teams list when necessary.
+When you bind directly to the [**CollectionViewSource**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.data.collectionviewsource), you imply that you want to bind to the current item in bindings where the path can't be found on the collection itself. You don't need to specify the `CurrentItem` property as the path for the binding, although you can add it if there's any ambiguity. For example, the [**ContentControl**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.contentcontrol) representing the team view has its [**Content**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.contentcontrol.content) property bound to the `Teams` `CollectionViewSource`. However, the controls in the [**DataTemplate**](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.datatemplate) bind to properties of the `Team` class because the `CollectionViewSource` automatically supplies the currently selected team from the teams list when necessary.
 
 ## See also
 

hub/apps/develop/data-binding/data-binding-and-mvvm.md

@@ -1,37 +1,38 @@
 ---
 ms.assetid: b7a8ec88-3013-4e5a-a110-fab3f20ee4bf
 title: Windows data binding and MVVM
-description: Data binding is at the core of the Model-View-ViewModel (MVVM) UI architectural design pattern, and enables loose coupling between UI and non-UI code.
-ms.date: 12/13/2022
-ms.topic: article
+description: Learn how data binding in the Model-View-ViewModel (MVVM) pattern enables loose coupling between UI and non-UI code for better maintainability.
+ms.date: 11/11/2025
+ms.topic: concept-article
 keywords: windows 10, windows 11, windows app sdk, winui, windows ui, mvvm
 ms.localizationpriority: medium
+# customer intent: As a Windows developer, I want to learn how data binding in the Model-View-ViewModel (MVVM) pattern enables loose coupling between UI and non-UI code so that I can improve maintainability.
 ---
 
 # Windows data binding and MVVM
 
-Model-View-ViewModel (MVVM) is a UI architectural design pattern for decoupling UI and non-UI code. With MVVM, you define your UI declaratively in XAML and use data binding markup to link it to other layers containing data and commands. The data binding infrastructure provides a loose coupling that keeps the UI and the linked data synchronized and routes user input to the appropriate commands.
+Model-View-ViewModel (MVVM) is a UI architectural design pattern that decouples UI and non-UI code. Learn how MVVM enables loose coupling using data binding in XAML to synchronize UI and data, improving maintainability and reducing dependencies.
 
-Because it provides loose coupling, the use of data binding reduces hard dependencies between different kinds of code. This makes it easier to change individual code units (methods, classes, controls, etc.) without causing unintended side effects in other units. This decoupling is an example of the *separation of concerns*, which is an important concept in many design patterns.
+Because it provides loose coupling, the use of data binding reduces hard dependencies between different kinds of code. This approach makes it easier to change individual code units (methods, classes, controls, and so on) without causing unintended side effects in other units. This decoupling is an example of the *separation of concerns*, which is an important concept in many design patterns.
 
 ## Benefits of MVVM
 
 Decoupling your code has many benefits, including:
 
 * Enabling an iterative, exploratory coding style. Change that is isolated is less risky and easier to experiment with.
-* Simplifying unit testing. Code units that are isolated from one another can be tested individually and outside of production environments.
-* Supporting team collaboration. Decoupled code that adheres to well-designed interfaces can be developed by separate individuals or teams, and integrated later.
+* Simplifying unit testing. You can test code units that are isolated from one another individually and outside of production environments.
+* Supporting team collaboration. Separate individuals or teams can develop decoupled code that adheres to well-designed interfaces and integrate it later.
 * Improving maintainability. Fixing bugs in decoupled code is less likely to cause regressions in other code.
 
-In contrast with MVVM, an app with a more conventional "code-behind" structure typically uses data binding for display-only data, and responds to user input by directly handling events exposed by controls. The event handlers are implemented in code-behind files (such as MainWindow.xaml.cs), and are often tightly coupled to the controls, typically containing code that manipulates the UI directly. This makes it difficult or impossible to replace a control without having to update the event handling code. With this architecture, code-behind files often accumulate code that isn't directly related to the UI, such as database-access code, which ends up being duplicated and modified for use with other windows.
+In contrast with MVVM, an app with a more conventional "code-behind" structure typically uses data binding for display-only data. It responds to user input by directly handling events exposed by controls. The event handlers are implemented in code-behind files (such as MainWindow.xaml.cs) and are often tightly coupled to the controls. They typically contain code that manipulates the UI directly. This structure makes it difficult or impossible to replace a control without having to update the event handling code. With this architecture, code-behind files often accumulate code that isn't directly related to the UI, such as database-access code, which ends up being duplicated and modified for use with other windows.
 
 ## App layers
 
-When using the MVVM pattern, an app is divided into the following layers:
+When you use the MVVM pattern, divide your app into the following layers:
 
-* The **model** layer defines the types that represent your business data. This includes everything required to model the core app domain, and often includes core app logic. This layer is completely independent of the view and view-model layers, and often resides partially in the cloud. Given a fully implemented model layer, you can create multiple different client apps if you so choose, such as Windows App SDK and web apps that work with the same underlying data.
-* The **view** layer defines the UI using XAML markup. The markup includes data binding expressions (such as [x:Bind](/windows/apps/develop/platform/xaml/x-bind-markup-extension)) that define the connection between specific UI components and various view-model and model members. Code-behind files are sometimes used as part of the view layer to contain additional code needed to customize or manipulate the UI, or to extract data from event handler arguments before calling a view-model method that performs the work.
-* The **view-model** layer provides data binding targets for the view. In many cases, the view-model exposes the model directly, or provides members that wrap specific model members. The view-model can also define members for keeping track of data that is relevant to the UI but not to the model, such as the display order of a list of items. The view-model also serves as an integration point with other services such as data access code. For simple projects, you might not need a separate model layer, but only a view-model that encapsulates all the data you need.
+* The **model** layer defines the types that represent your business data. This layer includes everything required to model the core app domain and often includes core app logic. This layer is completely independent of the view and view-model layers and often resides partially in the cloud. Given a fully implemented model layer, you can create multiple different client apps if you choose, such as Windows App SDK and web apps that work with the same underlying data.
+* The **view** layer defines the UI by using XAML markup. The markup includes data binding expressions (such as [x:Bind](/windows/apps/develop/platform/xaml/x-bind-markup-extension)) that define the connection between specific UI components and various view-model and model members. You can sometimes use code-behind files as part of the view layer to contain additional code needed to customize or manipulate the UI or to extract data from event handler arguments before calling a view-model method that performs the work.
+* The **view-model** layer provides data binding targets for the view. In many cases, the view-model exposes the model directly or provides members that wrap specific model members. The view-model can also define members for keeping track of data that is relevant to the UI but not to the model, such as the display order of a list of items. The view-model also serves as an integration point with other services such as data access code. For simple projects, you might not need a separate model layer, but only a view-model that encapsulates all the data you need.
 
 ## Basic and advanced MVVM