简介：一套基于WPF与Prism MVVM框架的交互式标注示例工程，面向需要为后台目标检测算法提供区域标注功能的开发人员，可应用在视频监控、电子围栏绘制、目标框选等场景。工程重点展示了如何动态添加控件，并支持鼠标拖动、缩放和旋转。压缩包内共752个文件，除了160个C#源代码和4个XAML视图文件外，还包含17个动态链接库与2个可直接运行的程序文件，其余为编译缓存、编辑配置和项目生成中间文件，整个资源包仅1.62MB；目前已有1520人浏览学习，属于受关注的WPF进阶示例。实现过程中采用Prism的MVVM架构，结合DryIoc容器管理依赖，涉及ItemsControl控件模板、Thumb拖动控件、Adorner装饰器、CommandParameter多参数传递以及通过UID查找指定类型子控件的技巧，读者可系统理解动态控件交互与电子围栏标注工具的完整实现思路，尤其适合希望深入WPF自定义控件与MVVM结合的开发人员参考借鉴。 不知道你有没有做过这种WPF项目：画布上允许用户随时动态添加控件，添加完之后还能用鼠标对控件进行拖动、缩放、旋转。我最近正好用 Prism + MVVM 把这套东西从头到尾完整做了一遍，涉及的坑比想象中多得多。先说结论：在 Prism MVVM 架构下，“动态添加控件”本身并不难，难的是让控件在用户手里像“活”的一样——拖得跟手、缩放不飘、旋转不跳，同时代码还不能写成一坨后置代码。如果你正准备做上位机界面、工艺流程图编辑器、模拟盘布局工具，或者只是想搞清楚 WPF 里自由变换的正确姿势，这篇文章应该能帮你少走不少弯路。
1. 一个看似普通的拖动操作，为什么会牵动整个架构
1.1 先看清楚需求背后的真实复杂度
把“动态添加控件并支持拖动缩放旋转”这句话拆开，很多人第一反应是：这不就是给 Canvas 上 Add 一个控件，然后挂几个鼠标事件吗？真上手就会发现，这里面其实叠着三套坐标系：Canvas 的布局坐标、控件自身的本地坐标、鼠标事件返回的屏幕坐标。控件一旦旋转，这三套坐标系立刻开始互相“打架”，位置算错一个像素，整个操作就飘了。
另外还有一层矛盾来自 MVVM。用户拖动的是视觉元素，但业务上希望改的是 ViewModel 里的属性值。WPF 的绑定机制可以把属性变化推送到界面，可是鼠标事件是在 UI 线程上发生的，事件处理器拿到的是一堆 Point 和 double，怎么把这些变成 ViewModel 听得懂的语言，同时又不让 View 的 Code-Behind 变成几百行的垃圾堆，才是这个需求真正考验人的地方。
1.2 我最终选择的整体方案
经过几轮踩坑和重构，我最后定下来一套比较稳的组合：动态元素用 ItemsControl + ObservableCollection 承载，每个元素对应一个 ElementViewModel；拖动用 Thumb 控件的手势事件，把 DragDelta 的增量翻译成 ViewModel 的 X/Y 属性；缩放和旋转用 RenderTransform 里的 TransformGroup，配合 RenderTransformOrigin 固定变换中心；跨模块通信（比如元素选中后要通知属性面板联动）交给 Prism 的 IEventAggregator。
这套方案最核心的设计思路是：界面上的交互手势全部收敛在 View 层，但所有状态变化都落到 ViewModel 的属性上。后面几章我会按“动态添加—拖动—缩放旋转—排错”这条链路逐段展开，每一步都讲清楚为什么要这么选。
2. 动态添加控件：集合绑定与 Prism 容器的配合
2.1 动态添加的本质是往集合里放 ViewModel
在 MVVM 里，“动态添加控件”这个动作的准确说法是：往一个 ObservableCollection 里追加一个 ViewModel 实例，界面上的 ItemsControl 会自动创建一个对应的视觉元素。你不需要手动 new 一个 TextBlock 然后调用 Canvas.Children.Add，手写 UI 树的做法在 MVVM 体系里基本是死路，既没法绑定命令，也没法序列化保存布局。
所以 MainViewModel 里最重要的就是一个元素集合：
public class MainViewModel : BindableBase { private readonly IContainerExtension _container; private readonly IEventAggregator _eventAggregator; public ObservableCollection<ElementViewModel> Elements { get; } = new(); public MainViewModel(IContainerExtension container, IEventAggregator eventAggregator) { _container = container; _eventAggregator = eventAggregator; } private DelegateCommand _addTextBoxCommand; public DelegateCommand AddTextBoxCommand => _addTextBoxCommand ??= new DelegateCommand(() => { var element = _container.Resolve<ElementViewModel>(); element.Title = $"TextBox_{Elements.Count + 1}"; element.X = 60 + Elements.Count * 20; element.Y = 60 + Elements.Count * 20; element.Width = 180; element.Height = 100; Elements.Add(element); }); }这里 Prism 容器的作用就体现出来了。ElementViewModel 如果构造函数里注入了 IEventAggregator 或者其他服务，直接用 _container.Resolve () 就能拿到一个依赖完整的实例。如果你把元素 VM 当成普通数据对象到处 new，后面一旦需要它参与事件通信或者访问公共服务，改造成本非常高。
2.2 ItemsControl 的绑定写法
画布部分我用 ItemsControl，ItemsPanel 换成 Canvas，每个元素的定位通过 ItemContainerStyle 绑定到 VM 的 X/Y，元素自身的宽度高度和变换通过 DataTemplate 绑定：
<ItemsControl ItemsSource="{Binding Elements}"> <ItemsControl.ItemsPanel> <ItemsPanelTemplate> <Canvas Background="Transparent" /> </ItemsPanelTemplate> </ItemsControl.ItemsPanel> <ItemsControl.ItemContainerStyle> <Style TargetType="ContentPresenter"> <Setter Property="Canvas.Left" Value="{Binding X}" /> <Setter Property="Canvas.Top" Value="{Binding Y}" /> </Style> </ItemsControl.ItemContainerStyle> <ItemsControl.ItemTemplate> <DataTemplate> <ContentControl Width="{Binding Width}" Height="{Binding Height}" RenderTransformOrigin="0.5,0.5"> <ContentControl.RenderTransform> <TransformGroup> <ScaleTransform ScaleX="{Binding ScaleX}" ScaleY="{Binding ScaleY}" /> <RotateTransform Angle="{Binding Angle}" /> </TransformGroup> </ContentControl.RenderTransform> <!-- 具体内容模板，可以是文本框、图表、设备状态块等 --> </ContentControl> </DataTemplate> </ItemsControl.ItemTemplate> </ItemsControl>这里有一点容易踩：Canvas.Left 和 Canvas.Top 必须放在 ItemContainerStyle 里，也就是作用在 ContentPresenter 这个容器上，而不是放在 DataTemplate 内部的某个控件上。因为 Canvas 附加属性只会对直接子元素生效，ItemsControl 生成的第一层视觉节点就是 ContentPresenter，所以 Setter 得写在这里。
2.3 为什么不建议用 RegionManager 管动态元素
我刚把需求接到 Prism 时，第一反应是“动态区域，用 Region 不就行了”，后来实际做下来发现这是一个坑。Prism 的 Region 机制是为模块化布局设计的，比如主窗口左边导航、右边内容、底部状态栏这种固定区域，它有视图缓存、激活/失活、依赖注入生命周期等能力。但动态画布上的元素是高频增删、自由坐标、带几何变换的，用 Region 去 Add 视图，很快就会遇到两个问题：一是每个元素都要走 Region 的激活流程，数量一多开销明显；二是 Region 的坐标定位和元素自身的 RenderTransform 完全是两套逻辑，强制揉在一起只会让代码更拧巴。
动态画布场景就应该老老实实用 ItemsControl + 集合绑定，让数据和视图的关系保持简单直接。Prism 在这套方案里负责的是 ViewModel 的依赖注入、命令绑定和事件聚合，各司其职，比硬套 Region 舒服得多。
3. 拖动：Thumb 把最麻烦的手势细节挡在了外面
3.1 自己写 MouseMove 纯粹是给自己挖坑
拖动一个元素，最朴素的办法是监听 MouseLeftButtonDown、MouseMove、MouseLeftButtonUp 三个事件，然后在 MouseMove 里计算相对位移。听起来简单，实际操作时会遇到一连串问题：鼠标移动太快导致移出控件区域收不到消息、鼠标捕获的时机和释放时机、多指触控的干扰、DPI 缩放带来的坐标偏差……每一样都要单独处理，处理完还会发现自己写了一套功能残缺的 Thumb。
WPF 自带的 Thumb 控件把这些手势细节都封装好了，它对外暴露 DragStarted、DragDelta、DragCompleted 三个事件。尤其是 DragDelta 的回调参数，直接告诉你这次拖动相对上次移动了多少，不用自己保存上次坐标。
private void OnDragDelta(object sender, DragDeltaEventArgs e) { if (sender is Thumb { DataContext: ElementViewModel vm }) { vm.X += e.HorizontalChange; vm.Y += e.VerticalChange; } }这个代码短得几乎没什么好解释，但背后有两个地方值得注意：e.HorizontalChange 是相对变化量，不是相对拖动起点的绝对偏移，所以用累加而不是赋值；Thumb 的 DataContext 自动继承自元素 VM，事件处理器里直接就能拿到 VM，不需要去 VisualTree 里翻 DataContext。
3.2 事件处理器只做翻译，业务逻辑留在 ViewModel
有人可能会问：写 OnDragDelta 事件处理器，是不是违背了 MVVM？我的观点是：这个事件处理器做的事情只是把 DragDelta 这个“手势增量”翻译成 vm.X 和 vm.Y 的赋值，没有碰任何控件对象、没有操作 UI 树、没有访问 Canvas，所以它依然是 View 层的薄薄一层胶水，核心状态仍然在 ViewModel 里。
如果你就是接受不了任何事件，也可以把 DragDelta 封装成附加行为，绑定到一个 ICommand 上。我两种都写过，结论是：对于 Thumb 这种事件参数比较特殊的控件，附加行为代码量反而更大，事件写法更直观。真正要避免的不是事件，而是事件里塞满 UI 逻辑。
3.3 拖动时如何让属性面板同步更新
拖动只是第一步，实际项目中往往还要求元素被移动后，右侧属性面板同步显示当前的 X/Y，或者另一个模块要根据位置变化重新计算连线。跨 ViewModel 通信这时候就该用 Prism 的 IEventAggregator。
我在 ElementViewModel 里改成这样：属性变更时发布一个位置变化事件，订阅方自行处理。
public class ElementPositionChangedEvent : PubSubEvent<ElementViewModel> { } // ElementViewModel 内部 private double _x; public double X { get => _x; set { if (SetProperty(ref _x, value)) { _eventAggregator.GetEvent<ElementPositionChangedEvent>().Publish(this); } } }MainViewModel 里订阅这个事件，收到通知后就更新属性面板选中项的引用。这个模式的好处是：拖动、代码修改位置、反序列化加载布局，任何一条路径改动 X/Y，下游都能收到通知，不会漏同步。
4. 缩放和旋转：RenderTransformOrigin 才是几何题的核心
4.1 为什么缩放不用改 Width 和 Height
做缩放功能时，最直觉的方案是拖动角落手柄，然后把控件的 Width 和 Height 改了。对于简单的矩形块这么做没问题，但遇到里面包着 TextBlock、按钮、图表等复杂内容的控件时，改 Width 和 Height 会导致内部重新布局，文字换行位置变化、子元素排列错乱，整个控件就像被人捏变形了一样，视觉上非常怪。
用 ScaleTransform 的效果完全不同。它只改变渲染结果，不触发元素内部的布局管线，文字和子元素的比例随着缩放一起变，整体观感是“整体放大缩小”，而不是“重新排版”。这一点在拖动角落手柄做实时预览时差别尤其明显，ScaleTransform 的响应更加流畅，基本不会卡顿。
<ContentControl Width="{Binding Width}" Height="{Binding Height}" RenderTransformOrigin="0.5,0.5"> <ContentControl.RenderTransform> <TransformGroup> <ScaleTransform ScaleX="{Binding ScaleX}" ScaleY="{Binding ScaleY}" /> <RotateTransform Angle="{Binding Angle}" /> </TransformGroup> </ContentControl.RenderTransform> </ContentControl>4.2 中心点才是缩放旋转不飘的定海神针
我刚实现缩放时遇到过一个典型的“飘移”问题：拖右下角手柄放大，结果控件不仅变大，整个位置还在往右下角跑。排查了很久才发现，问题出在 RenderTransformOrigin 没有设置，默认值是 (0,0)，也就是所有变换都以左上角为原点。缩放时左上角不动，右下角向外扩，看起来当然像整体往右下角跑。
把 RenderTransformOrigin 设为 "0.5,0.5" 后，所有变换都以控件中心为原点，缩放和旋转时中心点保持不动，视觉上就像控件在原地放大、原地转动。这是 WPF 里被提到很多次但实操中依然频繁踩坑的一个属性，值得单独强调。
对应的缩放手柄逻辑大致是这样：以右下角手柄为例，鼠标向右移动多少像素，ScaleX 就增加对应比例；向下移动多少像素，ScaleY 就增加对应比例。因为 ScaleX 是倍率，所以要除以原始宽度换算。
private void OnResizeDelta(object sender, DragDeltaEventArgs e) { if (sender is not Thumb { Tag: string direction, DataContext: ElementViewModel vm }) return; double dx = e.HorizontalChange; double dy = e.VerticalChange; if (direction.Contains("Right")) vm.ScaleX += dx / vm.Width; else if (direction.Contains("Left")) vm.ScaleX -= dx / vm.Width; if (direction.Contains("Bottom")) vm.ScaleY += dy / vm.Height; else if (direction.Contains("Top")) vm.ScaleY -= dy / vm.Height; vm.ScaleX = Math.Max(0.1, vm.ScaleX); vm.ScaleY = Math.Max(0.1, vm.ScaleY); }这里 Tag 是 XAML 里给每个角落手柄标的方向字符串，用来区分是哪个角在拖。左上角手柄往左拖，ScaleX 应该变大，但鼠标位移 dx 是负值，所以用减法才能得到正的增量。这块逻辑不难，但方向正负号非常容易搞反，最好在代码里写清楚注释。
4.3 旋转手柄：用 Atan2 把鼠标坐标翻译成角度
旋转手柄我放在了元素正上方中央。用户按住手柄拖动，元素应该实时跟着鼠标转。计算方式是：拿到鼠标在 Canvas 上的坐标，算出它与元素中心点连线的方向角，再映射成 RotateTransform 的 Angle。
private void OnRotateDelta(object sender, DragDeltaEventArgs e) { if (sender is not Thumb thumb || thumb.DataContext is not ElementViewModel vm) return; var canvas = FindParentCanvas(thumb); var mousePos = e.MouseDevice.GetPosition(canvas); var center = new Point(vm.X + vm.Width / 2, vm.Y + vm.Height / 2); double angle = Math.Atan2(mousePos.Y - center.Y, mousePos.X - center.X) * 180 / Math.PI; vm.Angle = angle + 90; }这个 +90 是因为手柄默认在正上方，而正上方方向角算出来是 -90 度，加 90 度后让控件的顶边跟着鼠标走，操作起来才跟手。FindParentCanvas 是我写的一个 VisualTreeHelper 辅助方法，从 Thumb 向上找 ItemsControl 的 Canvas 父级。如果你不想写辅助方法，也可以把 Canvas 的引用通过 Tag 或者附加属性传进来，效果一样。
4.4 旋转之后再缩放：坐标变换的进阶问题
如果控件旋转了，再拖角落手柄做缩放，直接用 DragDelta 的水平和垂直位移会不准确。因为此时手柄的“水平方向”已经不再是屏幕的水平方向，鼠标向右移并不完全等价于控件宽度方向增加。要做得精确，需要把鼠标坐标通过 RenderTransform 的逆变换转换到控件本地坐标系，然后把本地坐标系下的位移换算成 Scale 增量。
var inverse = transformGroup.Inverse; var localMousePos = inverse.Transform(e.MouseDevice.GetPosition(canvas));这个细节很多教程不会讲。如果你的项目只做水平垂直的粗略缩放，普通方案完全够用；但如果控件可以自由旋转，建议尽早把逆变换这套逻辑接进来，否则会出现“旋转 90 度后拖手柄却往反方向缩放”的诡异表现。
5. 实测排查：漂移、命中测试与性能
5.1 坐标漂移：先查 RenderTransformOrigin，再查绑定层级
旋转或缩放过程中元素位置突然乱跳，是这类需求里最高频的问题。我自己的排查顺序已经固定了：第一步检查 RenderTransformOrigin 有没有设成 0.5,0.5，第二步检查 Canvas.Left/Top 是否绑到了正确的 VM 属性上，第三步确认 ScaleTransform 的 CenterX/CenterY 没有被重复设置。
有一个容易被忽略的小坑：TransformGroup 里的 ScaleTransform 默认 CenterX/CenterY 都是 0，如果你在这里设置了中心点，同时又设置了 RenderTransformOrigin，两者会叠加计算，结果经常不是你预期的那样。我的建议是二选一：要么统一用 RenderTransformOrigin 控制中心，要么统一用 ScaleTransform 的 CenterX/CenterY，不要在同一个项目里混用两套机制。
5.2 命中测试：点击事件被控件的 Border 吃掉了
实现选中效果（点击元素显示虚线边框和手柄）时，我遇到一个很隐蔽的问题：元素外面包了一层带背景色的 Border，结果这层 Border 把鼠标点击全部拦截了，下面元素的命中测试永远不触发。后来逐个关闭 IsHitTestVisible 才定位到这个 Border 身上。
经验是：画布上的元素容器，能不用带背景的 Border 就不用；必须用的时候，背景尽量用 Transparent 而不是某种具体颜色。Panel 或者装饰层的 IsHitTestVisible 属性也要按需设置，否则很容易出现“点哪都是同一个元素”的现象。另外，ItemsControl 的 Canvas 面板一定要设置 Background="Transparent"，否则点击画布空白区域时事件直接穿透到更低层的控件，很多交互就失灵了。
5.3 性能：一次拖动别触发一整片级联布局
画布上元素数量少的时候，性能问题不明显；一旦元素超过一两百个，并且在 DragDelta 里频繁改 X/Y、Scale、Angle，每个属性变化都会触发设备端布局更新。如果每个元素还都通过事件聚合器广播了位置变化，那更是一场灾难，因为每个订阅者都要响应。
我的处理策略是分档：拖动过程中只做最必要的 UI 状态更新；松开鼠标后（DragCompleted）再统一提交一次完整的事件通知。对于缩放手柄这种高频触发的操作，也类似，实时改变 ScaleX/ScaleY，但属性面板的刷新可以节流到几百毫秒一次。实测下来，这个优化对流畅度的提升非常明显。
最后再说两句实战体会
整套方案做完之后，我的一个明显感受是：WPF 交互里最难的不是某个 API 不会调用，而是搞不清每一步操作到底落在了哪套坐标系里、这个状态的变更该由谁负责。Prism + MVVM 的价值不是帮你少写一个事件，而是逼着你在设计阶段就把这些边界想清楚。后面我把这套方案扩展到了 LiveCharts2 图表卡片和上位机实时设备状态块，新增控件类型只需要加一个 DataTemplate 和对应的 ViewModel，交互代码一行都没动。如果你也要做类似的需求，建议按照“动态添加—拖动—缩放—旋转”的顺序逐步加功能，每加一个动作之前都先想一想坐标变换的链路，会顺手很多。
本文还有配套的精品资源，点击获取
