WPF中的
TemplateSelector，说白了，就是给你一个机会，在运行时根据你的数据对象（或者说，根据你的业务逻辑）来动态选择应该使用哪个
DataTemplate。想象一下，你有一个列表，里面可能混杂着好几种不同类型或者不同状态的数据项，但你又想让它们在UI上呈现出完全不一样的样式和布局，这时候
TemplateSelector就派上大用场了。它让你摆脱了死板的“一种数据类型对应一种模板”的限制，赋予了UI极大的灵活性和表现力。
解决方案
要使用
TemplateSelector，核心思路是创建一个继承自
DataTemplateSelector的自定义类，并重写它的
SelectTemplate方法。在这个方法里，你就能编写自己的逻辑，判断传入的数据项应该匹配哪个
DataTemplate。
首先，你需要定义好你可能会用到的所有
DataTemplate。这些模板通常会放在资源的某个地方，比如
Window.Resources或
UserControl.Resources，并且给它们一个
x:Key以便引用。
<Window.Resources>
<DataTemplate x:Key="UrgentTaskTemplate">
<Border Background="Red" Margin="2" Padding="5">
<TextBlock Text="{Binding Title}" Foreground="White" FontWeight="Bold"/>
</Border>
</DataTemplate>
<DataTemplate x:Key="NormalTaskTemplate">
<Border Background="LightBlue" Margin="2" Padding="5">
<TextBlock Text="{Binding Title}" Foreground="DarkBlue"/>
</Border>
</DataTemplate>
<DataTemplate x:Key="CompletedTaskTemplate">
<Border Background="LightGreen" Margin="2" Padding="5">
<StackPanel Orientation="Horizontal">
<TextBlock Text="✔ " Foreground="Green"/>
<TextBlock Text="{Binding Title}" TextDecorations="Strikethrough" Foreground="Gray"/>
</StackPanel>
</Border>
</DataTemplate>
</Window.Resources>接下来，创建一个自定义的
TemplateSelector类。假设你的数据模型是
TaskItem，里面有一个
Status属性来指示任务状态。
using System.Windows;
using System.Windows.Controls;
public class TaskTemplateSelector : DataTemplateSelector
{
public DataTemplate UrgentTemplate { get; set; }
public DataTemplate NormalTemplate { get; set; }
public DataTemplate CompletedTemplate { get; set; }
public override DataTemplate SelectTemplate(object item, DependencyObject container)
{
if (item is TaskItem task)
{
switch (task.Status)
{
case TaskStatus.Urgent:
return UrgentTemplate;
case TaskStatus.Completed:
return CompletedTemplate;
default:
return NormalTemplate;
}
}
return base.SelectTemplate(item, container); // Fallback
}
}
// 示例数据模型
public class TaskItem
{
public string Title { get; set; }
public TaskStatus Status { get; set; }
}
public enum TaskStatus
{
Normal,
Urgent,
Completed
}注意，这里我把
DataTemplate作为属性暴露出来，这样在XAML中实例化
TaskTemplateSelector时可以直接绑定这些模板。这是一种很常见的做法，让选择器能够“知道”它有哪些模板可用。
最后，在你的XAML中实例化这个自定义的
TemplateSelector，并把它赋值给
ItemsControl（比如
ListBox、
ListView）的
ItemTemplateSelector属性。如果是单个
ContentControl，则使用
ContentTemplateSelector。
<Window x:Class="WpfApp.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:WpfApp" <!-- 确保命名空间正确 -->
Title="任务列表" Height="450" Width="800">
<Window.Resources>
<!-- DataTemplates如上所示 -->
<DataTemplate x:Key="UrgentTaskTemplate">...</DataTemplate>
<DataTemplate x:Key="NormalTaskTemplate">...</DataTemplate>
<DataTemplate x:Key="CompletedTaskTemplate">...</DataTemplate>
<!-- 实例化你的TemplateSelector -->
<local:TaskTemplateSelector x:Key="MyTaskSelector"
UrgentTemplate="{StaticResource UrgentTaskTemplate}"
NormalTemplate="{StaticResource NormalTaskTemplate}"
CompletedTemplate="{StaticResource CompletedTaskTemplate}"/>
</Window.Resources>
<Grid>
<ListBox ItemsSource="{Binding Tasks}"
ItemTemplateSelector="{StaticResource MyTaskSelector}"/>
</Grid>
</Window>在后台代码中，你需要设置
DataContext并填充
Tasks集合。
public partial class MainWindow : Window
{
public ObservableCollection<TaskItem> Tasks { get; set; }
public MainWindow()
{
InitializeComponent();
Tasks = new ObservableCollection<TaskItem>
{
new TaskItem { Title = "完成项目报告", Status = TaskStatus.Urgent },
new TaskItem { Title = "回复邮件", Status = TaskStatus.Normal },
new TaskItem { Title = "安排会议", Status = TaskStatus.Urgent },
new TaskItem { Title = "购买咖啡豆", Status = TaskStatus.Completed },
new TaskItem { Title = "学习WPF新特性", Status = TaskStatus.Normal }
};
this.DataContext = this;
}
}这样，当
ListBox渲染每个
TaskItem时，
TaskTemplateSelector就会根据
TaskItem的
Status属性，动态地选择并应用相应的
DataTemplate。这让我觉得，WPF在UI表现力上真是给了开发者足够的自由度，只要你肯花心思去组织你的代码和资源。
WPF TemplateSelector为什么能提升UI的灵活性和可维护性？
从我个人的经验来看，
TemplateSelector的引入，确实让WPF应用的UI层变得更加“聪明”和易于管理。它提升灵活性和可维护性，主要体现在几个方面：
首先，解耦了数据和视图的呈现逻辑。以前，如果想根据数据状态改变UI，你可能得写一堆
DataTrigger在
Style里，或者用
Converter来把数据转换成某个特定的值再通过
Trigger去匹配。这种方式在逻辑简单时还行，但一旦数据项的判断条件变得复杂，或者需要切换的模板数量增多，XAML就会变得异常臃肿和难以阅读。
TemplateSelector把这些复杂的判断逻辑全部封装到了C#代码里，让XAML保持纯粹，只负责声明“这里要用一个选择器”，而具体的选择规则则由C#代码来决定。这种分离使得各自的职责更清晰，修改起来也更方便。
其次，它支持更复杂的业务逻辑判断。
DataTrigger通常只能基于单个或少数几个属性的值进行判断。但如果你需要根据数据对象的多个属性组合、甚至一些外部状态来进行模板选择，
TemplateSelector的C#代码环境就显得游刃有余了。你可以在
SelectTemplate方法里调用服务、执行复杂的计算，或者查询其他数据源，这在纯XAML的
Trigger里是很难实现的。这种能力让UI能够更好地响应复杂的业务场景，而不是被简单的属性值所限制。
再者，提高了代码的复用性。一旦你编写了一个通用的
TemplateSelector，它就可以在应用中的多个地方被重用。比如，如果你有一个
UserStatusTemplateSelector，无论是在用户列表、用户详情卡片还是聊天窗口中显示用户头像和状态，都可以使用同一个选择器来保证一致的UI呈现。这避免了在不同地方重复编写相似的UI逻辑，减少了冗余，也降低了维护成本。当业务规则变化时，你只需要修改
TemplateSelector的C#代码，所有使用它的地方都会自动更新，这简直是维护者的福音。
最后，它让UI结构更清晰。当一个
ItemsControl中混合了多种视觉表现形式时，通过
TemplateSelector，我们一眼就能看出这个控件的模板是动态选择的，而不是固定死的。这比一大堆嵌套的
DataTrigger要直观得多。对于新加入的开发者来说，理解和上手也更快，因为它遵循了更接近命令式编程的逻辑。可以说，
TemplateSelector是WPF在复杂UI场景下，提供的一种优雅且高效的解决方案，它让我的代码看起来更整洁，也让我对UI的控制感更强。
在WPF中实现自定义TemplateSelector有哪些关键步骤和注意事项？
实现自定义
TemplateSelector听起来很简单，但实际操作中还是有些地方需要留心，才能让它既高效又健壮。我总结了一些关键步骤和注意事项：
关键步骤回顾（略有补充）：
-
定义所有必要的
DataTemplate： 这是基础，每个模板都应有
x:Key，并清晰地定义其视觉结构。模板应该尽可能地小巧和专注于单一职责，避免一个模板试图包含所有可能的UI元素。 创建自定义
DataTemplateSelector类： 继承
DataTemplateSelector。这一步是核心。 在选择器中暴露
DataTemplate属性（推荐做法）： 就像我上面示例中那样，将
DataTemplate作为公共属性暴露出来。这样做的好处是，你可以在XAML中直接将这些模板资源绑定到选择器的属性上，使得选择器与模板的关联关系一目了然，也方便XAML设计器预览。 重写
SelectTemplate(object item, DependencyObject container)方法：
item参数：这就是当前正在被渲染的数据对象。你需要把它转换为你的具体数据类型（比如
TaskItem），然后根据其属性进行判断。
container参数：这个参数代表了正在请求模板的UI元素（比如
ListBoxItem或
ContentPresenter）。虽然在简单的模板选择中不常用，但在某些高级场景下，你可能需要通过它来访问父级控件的资源或者属性。 实现你的选择逻辑：这是最关键的部分。确保你的逻辑覆盖了所有可能的
item状态，并且返回了正确的
DataTemplate。 处理
null或未匹配情况：如果没有任何模板匹配，或者
item不是你期望的类型，通常可以返回
null。WPF在
SelectTemplate返回
null时，会尝试使用默认的
DataTemplate（如果有通过
DataType定义的）或者
ToString()来显示数据。所以，确保你的选择器能够优雅地处理这些边缘情况。 在XAML中实例化并绑定： 在资源中创建
TemplateSelector的实例，并将其绑定到
ItemsControl的
ItemTemplateSelector或
ContentControl的
ContentTemplateSelector属性。
注意事项：
性能考量：SelectTemplate方法可能会被频繁调用，尤其是在大型列表或虚拟化控件中。因此，其内部的逻辑必须尽可能高效。避免在
SelectTemplate中执行耗时的操作，比如复杂的数据库查询、网络请求或者大量的计算。如果确实需要这些数据，考虑在数据加载时就预处理好，或者使用异步加载，并在数据准备好后通知UI更新。 资源查找效率： 如果你的
DataTemplate不是通过属性直接暴露给
TemplateSelector，而是在
SelectTemplate内部通过
container.FindResource()或
Application.Current.FindResource()来查找，这可能会带来一定的性能开销。虽然查找资源本身很快，但频繁查找还是不如直接引用属性来得快。所以，我个人更倾向于通过属性注入模板。 可测试性： 将复杂的选择逻辑封装在
SelectTemplate中，使得这部分逻辑更容易进行单元测试。你可以模拟不同的
item对象，然后调用
SelectTemplate来验证它是否返回了正确的模板。这对于确保UI行为的正确性至关重要。 XAML设计时支持： 如果你的
TemplateSelector依赖于运行时数据，那么在XAML设计器中可能无法正确预览UI。为了解决这个问题，你可以考虑为设计器提供一个默认模板，或者使用设计时数据（
d:DataContext）来模拟数据，以便在设计时就能看到大致的效果。
DependencyObject container的妙用： 这个参数不仅仅是提供一个上下文，它实际上是当前数据项的容器，比如
ListBoxItem。你可以通过它访问到一些父级控件的属性，甚至可以通过
VisualTreeHelper向上遍历视觉树来获取更多信息。这在一些非常复杂的场景下会很有用，但通常情况下，我们主要还是依赖
item本身的数据。不过，一旦你需要用到它，会发现它非常强大。
在我看来，掌握这些，你就能游刃有余地使用
TemplateSelector来构建动态且富有表现力的WPF界面了。
除了TemplateSelector，WPF还有哪些方法可以实现数据模板的动态切换？它们各自的适用场景是什么？
TemplateSelector确实是WPF中实现数据模板动态切换的利器，但它并非唯一的选择。WPF提供了好几种机制来处理数据模板的选择，每种都有其独特的适用场景和优缺点。理解这些不同的方法，能帮助我们根据具体需求选择最合适的方案，避免过度设计或陷入困境。
基于DataType
的隐式DataTemplate
：
Resources中定义
DataTemplate时，不给它
x:Key，而是设置
DataType="{x:Type local:YourDataType}"。WPF的ContentPresenter或
ItemsControl在显示数据时，如果发现数据项的类型与某个隐式
DataTemplate的
DataType匹配，就会自动应用这个模板。 适用场景： 这是最简单、最常用的模板选择方式，适用于不同数据类型需要完全不同视觉表现的场景。比如，你有一个
ObservableCollection<object>，里面混杂着
Person对象和
Company对象，你可以分别为
Person和
Company定义隐式模板，WPF会自动为你渲染。它非常适合那些类型明确且固定不变的模板映射。 优缺点： 优点是极其简洁，无需编写任何C#代码，完全声明式。缺点是它只认数据类型，无法根据数据项的内部属性值或状态来动态切换模板。
ContentControl.ContentTemplate
与DataTrigger
/ Converter
结合：
ContentControl），你可以通过
ContentTemplate属性指定一个模板。如果需要动态切换，可以在
ContentControl的
Style中使用
DataTrigger来根据
Content的某个属性值，切换
ContentTemplate属性绑定的模板。或者，你也可以使用
Converter将
Content的某个属性值转换成一个
DataTemplate的
x:Key，再通过
DynamicResource或
StaticResource查找。 适用场景： 适用于单个数据项的模板切换，且切换逻辑相对简单，基于一两个属性的判断。例如，一个显示用户状态的
ContentControl，根据
User.IsOnline属性来显示“在线”或“离线”模板。 优缺点： 优点是对于简单场景，纯XAML实现，可读性尚可。缺点是当逻辑复杂或模板数量增多时，
DataTrigger会变得非常冗长和难以管理。它也不适用于
ItemsControl中每个项目都需要独立模板选择的场景（虽然你可以对
ItemContainerStyle做文章，但那更复杂）。
ItemsControl.ItemContainerStyle
与DataTrigger
：
ItemsControl（如
ListBox）的
ItemContainerStyle属性可以用来修改每个数据项的容器（比如
ListBoxItem）的样式。你可以在这个
Style中定义
DataTrigger，根据数据项的属性来修改容器的某些属性，甚至包括容器的
ContentTemplate（但这通常会导致一些复杂性，因为
ContentTemplate是在容器内部）。 适用场景： 更多地用于修改容器本身的视觉效果，例如根据数据项状态改变
ListBoxItem的背景色、边框等。偶尔也会用来间接影响数据模板，但这并不是直接切换数据模板的主流方式。 优缺点： 优点是能够控制每个数据项容器的样式。缺点是它主要是针对容器，而不是直接针对数据模板。如果需要直接切换数据模板，这种方式会显得有些绕弯子。
在我看来，这几种方法各有侧重：
DataType隐式模板是最基础、最省心的选择，只要你的数据类型是固定的，并且每种类型都有一个专属的视觉表现，那就用它。它就像是WPF给你预设的“默认模式”。
DataTrigger结合
ContentTemplate适用于“小而美”的单项内容切换，当你的条件判断非常直接、且模板数量不多时，纯XAML的简洁性会让你感到舒适。
TemplateSelector则是处理复杂业务逻辑、多条件判断、或者需要在
ItemsControl中为每个数据项提供高度自定义视觉表现的终极武器。它把选择逻辑从XAML中抽离出来，让代码更清晰，也更易于维护和扩展。当你发现
DataTrigger已经无法满足你的需求，或者XAML变得难以阅读时，就该果断转向
TemplateSelector了。
选择哪种方法，最终还是取决于你的具体需求、团队的编码习惯以及对项目复杂度的预估。我个人在项目里，如果遇到超过两种模板切换，或者切换逻辑需要访问多个属性甚至外部状态时，几乎都会毫不犹豫地选择
TemplateSelector。它给了我最大的控制权和灵活性。
